Claude Checkpoint MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CHECKPOINT_PROJECT_ROOT | No | Overrides the project root. The path must be absolute and must be an existing directory. If not set, the server falls back to the client's first file:// root, or the server process's working directory. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| save_session_checkpointA | 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. |
| load_session_checkpointA | Load the project's .claude-checkpoint and return a compact brief of the previous session's goal, progress, next steps, touched files and recent commands, plus which files changed since it was saved. Call at the start of a session or when the user asks to resume. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools are the exact inverse of each other: save_session_checkpoint writes state, load_session_checkpoint reads it. There is no plausible scenario where an agent would confuse the two, and the descriptions reinforce the trigger conditions for each.
Both tools follow a strict verb_noun pattern (save_session_checkpoint / load_session_checkpoint) on the same object, so the pair reads as a coherent symmetric API.
Two tools is on the thin side, but the domain is genuinely narrow — persisting and restoring a single checkpoint file — so a save/load pair is the natural minimum surface and each tool clearly earns its place.
Save plus load covers the core lifecycle: checkpoint on milestones and restore on a fresh session. Minor gaps exist (no delete/clear, no listing or diffing of multiple historical checkpoints), but a single-file design means agents can work around these.