Skip to main content
Glama
Leviathan0x0

Chronicle MCP

by Leviathan0x0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Save Handoff Receipt

save_handoff_receipt

Record completed work and required next steps as a workspace handoff receipt before stopping or transferring work, so another agent can resume with clear obligations and evidence.

Instructions

Record what this agent run did and what the next agent must do, as a handoff receipt for the current workspace. Use it before stopping or handing work to another agent or model; read the current state with get_handoff_status. A receipt with status 'open' (the default) marks the workspace as blocked until a later receipt supersedes it with status 'closed' and a closure (closed_by, closed_at, closure_basis). It becomes stale automatically when any file listed in invalidation.stale_if changes after it was saved. Receipts are stored as new JSON files in the archive (never overwritten), indexed, and ranked first in search_history. Returns the saved file name and its receipt_id (pass that as 'supersedes' later).

Input Schema

NameRequiredDescriptionDefault
clientNoArchive namespace (a subfolder of the chats directory). Built-in: 'default', 'cursor', 'chatgpt', 'claude'; any other name creates its own subfolder. Omit to use 'default'.default
statusNo'open' (work outstanding, blocks the workspace) or 'closed' (finished; needs 'closure').open
closureNoRequired to close: {'closed_by': str, 'closed_at': ISO-8601 str, 'closure_basis': str, 'closure_evidence': str}.
evidenceYesProof: {'checks_run': [{'command': str, 'exit_code': int, 'stdout_summary': str}], 'missing_evidence': [str] (checks skipped or not yet run)}.
receipt_idNoExplicit receipt id. Defaults to '<workspace-hash>_<unix-time>'.
supersedesNoreceipt_id of the earlier receipt this one replaces, forming a chain.
work_stateYesWhat was done: {'touched_surfaces': [{'file_path': str, 'summary': str, 'why': str}], 'dependencies': [str]}.
obligationsYesWhat was promised: {'promise': str (the goal), 'scope': [str] (areas or files in scope)}.
invalidationYesWhen to distrust this receipt and what to do next: {'stale_if': [{'file_path': str} or {'glob_pattern': str}], 'next_safe_action': str (a direct instruction for the next agent)}.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv1.6.2
    • addedInput schema / properties / client / description
      Added value: +"Archive namespace (a subfolder of the chats directory). Built-in: 'default', 'cursor', 'chatgpt', 'claude'; any other name creates its own subfolder. Omit to use 'default'."
    • addedInput schema / properties / closure / description
      Added value: +"Required to close: {'closed_by': str, 'closed_at': ISO-8601 str, 'closure_basis': str, 'closure_evidence': str}."
    • addedInput schema / properties / evidence / description
      Added value: +"Proof: {'checks_run': [{'command': str, 'exit_code': int, 'stdout_summary': str}], 'missing_evidence': [str] (checks skipped or not yet run)}."
    • addedInput schema / properties / invalidation / description
      Added value: +"When to distrust this receipt and what to do next: {'stale_if': [{'file_path': str} or {'glob_pattern': str}], 'next_safe_action': str (a direct instruction for the next agent)}."
    • addedInput schema / properties / obligations / description
      Added value: +"What was promised: {'promise': str (the goal), 'scope': [str] (areas or files in scope)}."
    • addedInput schema / properties / receipt_id / description
      Added value: +"Explicit receipt id. Defaults to '<workspace-hash>_<unix-time>'."
    • addedInput schema / properties / status / description
      Added value: +"'open' (work outstanding, blocks the workspace) or 'closed' (finished; needs 'closure')."
    • addedInput schema / properties / supersedes / description
      Added value: +"receipt_id of the earlier receipt this one replaces, forming a chain."
    • addedInput schema / properties / work_state / description
      Added value: +"What was done: {'touched_surfaces': [{'file_path': str, 'summary': str, 'why': str}], 'dependencies': [str]}."
  2. First observedv1.5.4

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=false) but say nothing about lifecycle semantics, and the description fills that gap in detail: an 'open' receipt blocks the workspace until a 'closed' receipt with a closure supersedes it, staleness is automatic via invalidation.stale_if, and receipts are written as new JSON files that are never overwritten. That last point independently corroborates the non-idempotent, non-destructive annotation profile.

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?

Purpose is front-loaded in the first clause, then usage, then lifecycle behavior, then return values -- a sensible ordering with no filler sentences. The second paragraph is dense with chained conditions and runs long, though every clause conveys a distinct behavioral fact.

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 9-parameter, four-required, nested-object mutation with a large blast radius, the description supplies the state machine (open/closed/supersedes/stale) an agent must understand to call it correctly. It also covers the chaining contract, which is the one thing the schema and output schema cannot convey on their own.

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 the per-field documentation is already carried by the schema and baseline 3 applies. The description still adds cross-parameter semantics the schema cannot express: the default 'open' status is tied to the workspace-blocking behavior and the closure requirement, and the returned receipt_id is explicitly named as the value to pass into 'supersedes' later.

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 opens with a specific verb and resource: record what this run did and what the next agent must do, as a handoff receipt scoped to the current workspace. That is clearly distinguishable from the read-side sibling get_handoff_status, which it names explicitly in the next sentence.

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 gives an explicit trigger ('before stopping or handing work to another agent or model') and routes the agent to get_handoff_status when the intent is inspection rather than recording. It does not state any case where the tool should not be used (e.g. trivial runs with nothing to hand off), so it stops short of full when/when-not coverage.

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

Deploy Server

Other Tools