Claude Checkpoint MCP

Overview Schema Source Related Servers Discussions Admin

Save session checkpoint

save_session_checkpoint

Save session goal, progress, and modified files to a .claude-checkpoint file so a new session can resume after crashes, /clear, or context limits without re-exploring.

Instructions

Save the current session's goal, progress, touched files and recent commands to a .claude-checkpoint file in the project, so a new session can resume after a crash, /clear, or context limit without re-exploring. Call after finishing a milestone, before risky operations, and when the conversation is getting long. Git branch, HEAD and uncommitted files are captured automatically.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`goal`	Yes	The primary objective of the session, in one or two sentences.
`mode`	No	replace: overwrite the checkpoint. merge: update the existing one, appending commands, decisions and files.	replace
`tasks`	No	Sub-goals with their status. In merge mode, tasks with the same description are updated.
`summary`	No	Where things stand: what works, what is broken, what you were in the middle of.
`decisions`	No	Key decisions, constraints, and dead ends to avoid repeating.
`nextSteps`	No	Concrete next actions, in order, for whoever resumes.
`projectRoot`	No	Absolute path of the project. Defaults to the client's workspace root or the server's working directory.
`modifiedFiles`	No	Files you changed, with an optional note. Uncommitted git changes are detected automatically; list files here to annotate them or to include committed ones.
`recentCommands`	No	Recent significant terminal commands (builds, tests, migrations), oldest first, with exit codes and a short note on the outcome. Secrets are redacted automatically.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	Yes
`path`	Yes
`bytes`	Yes
`counts`	Yes
`warnings`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 15, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations declare it is a non-read-only, non-idempotent, non-destructive local write, and the description adds real context beyond that: it writes a named file into the project, captures git branch/HEAD/uncommitted files automatically, and states the failure scenarios (crash, /clear, context limit) it protects against. It stops short of describing what a replace does to prior content versus merge beyond what the schema already says.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, zero filler: what is written and where, why it exists, when to call it, and what is captured automatically. The most decision-relevant content is front-loaded in the first sentence.

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?

An output schema exists, so return values need no explanation, and the annotations cover the safety profile. Combined with explicit triggers, automatic git capture, and the target file location, an agent has everything needed to decide when and how to call this.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across all 9 parameters, so the schema already carries the semantics (including the replace/merge distinction and the auto-detection note on modifiedFiles). The description touches the same fields at a high level without adding syntax or format detail, so the baseline 3 applies.

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 (save) and a specific artifact (.claude-checkpoint file in the project) plus the exact payload (goal, progress, touched files, recent commands) and the payoff (resume without re-exploring). The save-vs-load framing cleanly distinguishes it from the load_session_checkpoint sibling.

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?

Gives three concrete triggers: after finishing a milestone, before risky operations, and when the conversation is getting long. That is actionable context, but it names no exclusion or alternative (e.g., 'use load_session_checkpoint to read one back'), which would be needed for a 5.

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

Deploy Server