Skip to main content
Glama

claude-checkpoint-mcp

Save your Claude Code session state locally, so a crash, /clear, or context limit doesn't make Claude rebuild context from scratch.

License: MIT Node.js ≥ 20 MCP M8ven Score

claude-checkpoint-mcp is a local Model Context Protocol server with two tools:

  • save_session_checkpoint writes your session's working state to a small JSON file in the project.

  • load_session_checkpoint turns that file back into a compact resume brief.

It runs entirely on your machine. Nothing is sent anywhere.


Contents


Related MCP server: basic-memory

Why: stop paying twice for the same context

A long Claude Code session builds up a lot of context:

  • what you're trying to do;

  • which approaches already failed;

  • which files matter;

  • which test is still red.

Several things can wipe that out mid-task:

  • a terminal crash, SSH drop, or laptop sleep;

  • running out of context window;

  • a /clear to get a fresh window.

The next session starts cold. To get back to where you were, Claude has to rebuild that context:

  • Re-reading files to work out what was changed and why. Every file read is input tokens.

  • Re-running exploration: grep, git diff, ls, test runs, all just to rediscover state.

  • Re-explaining. You retype the goal, the constraints, and the dead ends, or Claude rediscovers the dead ends the hard way.

Each of those turns resends the growing conversation as input, so the cost compounds.

claude-checkpoint-mcp swaps that rebuild for one small, structured read:

Without a checkpoint

With load_session_checkpoint

Restoring the goal & constraints

You retype them, or Claude infers them

One section of the brief

Knowing what's done vs. pending

Re-derived from code and git

Task list with statuses

Knowing which files matter

Broad re-reading

Exact list of touched files, with notes

Knowing what changed since

Re-read everything to be safe

Only files whose content actually changed are flagged

Remembering failed attempts

Often repeated

Recorded under Decisions & gotchas

The resume brief for a typical session is about 1.2 KB of markdown, a few hundred tokens. The example below is real output at that size.

The biggest saving comes from drift detection. At save time, the server records a content hash for every file with uncommitted changes. On load, it compares those hashes against the working tree and tells Claude exactly which files changed after the checkpoint. Everything else in the brief can be trusted as-is, so Claude re-reads only what it has to.


How it works

  Session 1                                     Session 2 (after crash / /clear)
  ─────────                                     ────────────────────────────────
  Claude ──save_session_checkpoint──┐       ┌──load_session_checkpoint── Claude
         goal, tasks, summary,      │       │   compact markdown brief
         next steps, decisions,     ▼       │   + "changed since checkpoint"
         files, commands      ┌─────────────────────┐
                              │ <project>/          │
     server adds:             │ .claude-checkpoint  │◀── git: branch, HEAD,
     git branch/HEAD,         │ .claude-checkpoint  │    dirty files + hashes
     dirty files + hashes,    │   .prev (backup)    │
     redacts secrets          └─────────────────────┘
  • Claude supplies the meaning: the goal, progress, decisions, next steps, and which commands mattered.

  • The server supplies the facts: git branch and HEAD, every uncommitted or untracked file with its content hash, and timestamps.

  • The server instructions teach Claude when to act. Claude is told to load at the start of a session and to save after milestones, before risky operations, and when the conversation gets long. It doesn't need to be prompted every time.


Installation

Requirements: Node.js 20+ and git. Git is optional, but without it you lose drift detection.

git clone https://github.com/tenlean/claude-checkpoint-mcp.git
cd claude-checkpoint-mcp
npm install
npm run build

The server entry point is now at dist/index.js.


Configuration

Claude Code

As a plugin (easiest). This repo is also a Claude Code plugin marketplace. You don't need to clone or build anything:

claude plugin marketplace add tenlean/claude-checkpoint-mcp
claude plugin install claude-checkpoint-mcp@tenlean

Restart Claude Code, then /mcp should show plugin:claude-checkpoint-mcp:claude-checkpoint as connected.

Manual setup. If you cloned the repo, register the server once for your user account, so it's available in every project:

# Run from the claude-checkpoint-mcp directory
claude mcp add --scope user checkpoint -- node "$PWD/dist/index.js"

Use an absolute path. A user-scoped server is launched from whichever project you open Claude Code in. A relative path like ./dist/index.js would resolve against that project, not this repo. "$PWD/dist/index.js" expands to the absolute path when you run the command, which is what gets saved.

Check that it's registered:

claude mcp list

Inside a session, /mcp should show checkpoint as connected.

Project-scoped alternative. To share the server with a team through version control, add it to the project's .mcp.json:

{
  "mcpServers": {
    "checkpoint": {
      "command": "node",
      "args": ["/absolute/path/to/claude-checkpoint-mcp/dist/index.js"]
    }
  }
}

Either way, add the checkpoint files to the project's .gitignore, or to your global gitignore:

.claude-checkpoint*

Claude Desktop (claude_desktop_config.json)

Open the config file:

OS

Path

macOS

~/Library/Application Support/Claude/claude_desktop_config.json

Windows

%APPDATA%\Claude\claude_desktop_config.json

Add the server under mcpServers, using the absolute path to your local build:

{
  "mcpServers": {
    "checkpoint": {
      "command": "node",
      "args": ["/absolute/path/to/claude-checkpoint-mcp/dist/index.js"],
      "env": {
        "CHECKPOINT_PROJECT_ROOT": "/absolute/path/to/your/project"
      }
    }
  }
}

Restart Claude Desktop after saving the file.

Claude Desktop has no notion of a "current project". Use CHECKPOINT_PROJECT_ROOT to set the default project, or have Claude pass projectRoot on each call ("save a checkpoint for /home/me/code/my-app"). See project root resolution.

Other MCP clients

Any MCP client that supports the stdio transport can run the server:

node /absolute/path/to/claude-checkpoint-mcp/dist/index.js

Usage

The server's built-in instructions cover the common cases automatically. You can also ask Claude directly.

Save:

  • "Checkpoint our progress."

  • "Save a checkpoint before you run the migration."

  • "Update the checkpoint. Merge in what we just did."

Resume (in a fresh session):

  • "Resume where we left off."

  • "Load the checkpoint and continue."

Example resume brief

This is real output from load_session_checkpoint. In the scenario, one file was committed unchanged after the save, and a teammate then edited session.ts:

# Resuming: my-app (checkpoint saved 2m ago, 2026-10-08 02:23:55 UTC)
Branch `feat/github-oauth` @ b2ef1b591 (uncommitted changes)

## Goal
Add GitHub OAuth login with persistent sessions

## Tasks
- [x] OAuth callback route
- [~] Session cookie persistence
- [ ] Logout endpoint

## Where things stand
Callback exchanges the code and creates a session, but the cookie is dropped on reload. Suspect SameSite/secure flags in dev.

## Next steps
1. Set sameSite: 'lax' and secure only in production in src/auth/session.ts
2. Re-run npm test -- auth
3. Start the logout endpoint

## Decisions & gotchas
- Use iron-session, not express-session (needs edge runtime support)
- Don't mock the GitHub API in e2e tests; use the recorded fixtures in test/fixtures

## Files touched (3)
- src/auth/session.ts (M) — cookie options
- src/auth/callback.ts (M)
- src/auth/session.spec.ts (??)

## Recent commands (last 2, oldest first)
- ✓ `GITHUB_CLIENT_SECRET=«redacted» npm run dev`
- ✗ exit 1 `npm test -- auth` — 2 failing in session.spec.ts: cookie missing after reload

## Since this checkpoint
- 1 new commit(s) on HEAD
- ⚠ Changed after the checkpoint, re-read before editing: `src/auth/session.ts`

callback.ts was committed after the save, but its content didn't change, so it isn't flagged. Only session.ts needs to be re-read.

Task markers: [x] done · [~] in progress · [ ] pending · [!] blocked.


Tool reference & examples

save_session_checkpoint

Writes <projectRoot>/.claude-checkpoint.

Parameter

Type

Required

Description

goal

string (≤ 500)

✅

Primary objective of the session

tasks

{ description, status }[] (≤ 30)

status: pending · in_progress · done · blocked

summary

string (≤ 4000)

Where things stand: what works, what's broken, what you were in the middle of

nextSteps

string[] (≤ 20)

Ordered next actions for whoever resumes

decisions

string[] (≤ 20)

Key decisions, constraints, dead ends to avoid

modifiedFiles

{ path, note? }[] (≤ 100)

Files to annotate, or committed files to include. Uncommitted git changes are detected automatically. Absolute paths inside the project are stored as relative.

recentCommands

{ command, exitCode?, note? }[] (≤ 50)

Significant commands, oldest first. Secrets are redacted.

mode

"replace" | "merge"

Default replace. See below.

projectRoot

string (absolute)

Overrides root resolution

Full save:

{
  "goal": "Add GitHub OAuth login with persistent sessions",
  "tasks": [
    { "description": "OAuth callback route", "status": "done" },
    { "description": "Session cookie persistence", "status": "in_progress" },
    { "description": "Logout endpoint", "status": "pending" }
  ],
  "summary": "Callback exchanges the code and creates a session, but the cookie is dropped on reload. Suspect SameSite/secure flags in dev.",
  "nextSteps": [
    "Set sameSite: 'lax' and secure only in production in src/auth/session.ts",
    "Re-run npm test -- auth"
  ],
  "decisions": ["Use iron-session, not express-session (needs edge runtime support)"],
  "modifiedFiles": [{ "path": "src/auth/session.ts", "note": "cookie options" }],
  "recentCommands": [
    { "command": "GITHUB_CLIENT_SECRET=gh_live_8f2a91 npm run dev", "exitCode": 0 },
    { "command": "npm test -- auth", "exitCode": 1, "note": "2 failing in session.spec.ts" }
  ]
}

Response (text shown to the model):

Checkpoint saved to /home/me/code/my-app/.claude-checkpoint (2202 bytes, replace).
3 task(s), 3 file(s), 2 command(s) on feat/github-oauth@b2ef1b591.
⚠ Redacted 1 secret-looking value(s).

Incremental update with merge:

{
  "goal": "Add GitHub OAuth login with persistent sessions",
  "mode": "merge",
  "tasks": [
    { "description": "Session cookie persistence", "status": "done" },
    { "description": "Logout endpoint", "status": "in_progress" }
  ],
  "recentCommands": [{ "command": "npm test -- auth", "exitCode": 0, "note": "all green" }]
}

Field

replace

merge

goal

set

set

tasks

set

updated by matching description; new tasks appended

summary, nextSteps

set

replaced if provided, otherwise kept

decisions

set

appended (deduplicated)

recentCommands

set

appended; the oldest are dropped beyond 50

modifiedFiles

fresh git scan + provided

fresh git scan + provided + previously recorded

id, createdAt

new

preserved

Structured output (structuredContent):

{
  "path": "/home/me/code/my-app/.claude-checkpoint",
  "bytes": 2202,
  "mode": "replace",
  "counts": { "tasks": 3, "modifiedFiles": 3, "recentCommands": 2, "redactions": 1 },
  "warnings": ["Redacted 1 secret-looking value(s)."]
}

load_session_checkpoint

Read-only. Reads the checkpoint, checks for drift, and returns the brief.

Parameter

Type

Required

Description

format

"brief" | "full"

Default brief (markdown, as above). full returns the complete checkpoint JSON plus drift.

projectRoot

string (absolute)

Overrides root resolution

Examples:

{}
{ "format": "full", "projectRoot": "/home/me/code/my-app" }

Structured output (structuredContent):

{
  "found": true,
  "path": "/home/me/code/my-app/.claude-checkpoint",
  "fromBackup": false,
  "updatedAt": "2026-10-08T02:23:55.477Z",
  "drift": {
    "branchChanged": false,
    "currentBranch": "feat/github-oauth",
    "commitsSince": 1,
    "changedSince": ["src/auth/session.ts"]
  },
  "warnings": []
}

If no checkpoint exists, the tool returns found: false with a "nothing to resume" message. That isn't treated as an error.

How the project root is chosen

  1. The projectRoot argument

  2. The CHECKPOINT_PROJECT_ROOT environment variable

  3. The client's first file:// root, if the client supports MCP roots

  4. The server process's working directory

The path must be absolute and must be an existing directory. Symlinks are resolved. The file is always written at exactly <root>/.claude-checkpoint.


The .claude-checkpoint file

This is plain, versioned JSON, so it's easy to read, diff, or edit by hand. Real example:

{
  "version": 1,
  "id": "ee5507c0-855e-44a5-85c1-d97b767537c9",
  "createdAt": "2026-10-08T02:23:55.477Z",
  "updatedAt": "2026-10-08T02:23:55.477Z",
  "generator": { "name": "claude-checkpoint-mcp", "version": "0.1.0" },
  "project": { "name": "my-app" },
  "git": {
    "branch": "feat/github-oauth",
    "head": "b2ef1b5919ee5d456ea146c9362a7abc92b1e556",
    "dirty": true
  },
  "goal": {
    "primary": "Add GitHub OAuth login with persistent sessions",
    "tasks": [
      { "description": "OAuth callback route", "status": "done" },
      { "description": "Session cookie persistence", "status": "in_progress" },
      { "description": "Logout endpoint", "status": "pending" }
    ]
  },
  "summary": "Callback exchanges the code and creates a session, but the cookie is dropped on reload. Suspect SameSite/secure flags in dev.",
  "nextSteps": [
    "Set sameSite: 'lax' and secure only in production in src/auth/session.ts",
    "Re-run npm test -- auth",
    "Start the logout endpoint"
  ],
  "decisions": [
    "Use iron-session, not express-session (needs edge runtime support)",
    "Don't mock the GitHub API in e2e tests; use the recorded fixtures in test/fixtures"
  ],
  "modifiedFiles": [
    { "path": "src/auth/session.ts", "status": "M", "source": "git", "note": "cookie options", "hash": "9ec893ef673dac860e7e2b6fcaad602983eeb0b1" },
    { "path": "src/auth/callback.ts", "status": "M", "source": "git", "hash": "f3ecc849c3875d4f11bb42ae0e5ab6c71931d7f1" },
    { "path": "src/auth/session.spec.ts", "status": "??", "source": "git", "hash": "9daeafb9864cf43055ae93beb0afd6c7d144bfa4" }
  ],
  "recentCommands": [
    { "command": "GITHUB_CLIENT_SECRET=«redacted» npm run dev", "exitCode": 0, "at": "2026-10-08T02:23:55.477Z" },
    { "command": "npm test -- auth", "exitCode": 1, "note": "2 failing in session.spec.ts: cookie missing after reload", "at": "2026-10-08T02:23:55.477Z" }
  ],
  "meta": { "redactions": 1, "truncated": false }
}

Field

Notes

version

Schema version. Older versions are migrated on load; unknown versions are rejected.

id / createdAt

Stable across merge saves; new on replace

git

null outside a git repo, or before the repo's first commit

modifiedFiles[].status

Git porcelain code (M, A, D, R, ??), or M for files reported only by Claude

modifiedFiles[].source

git (detected) or agent (reported by Claude, or carried over from an earlier merge)

modifiedFiles[].hash

Git blob hash of the working-tree content at save time; drives drift detection

meta.truncated

true if anything was dropped to fit list or size limits

Paths are always relative to the project root. The file never stores absolute paths.


Security & privacy

  • Local only. There are no network calls. The server reads git metadata and one file, and writes one file.

  • Secret redaction. The following are replaced with «redacted» in commands, notes, summaries, tasks and decisions before anything touches disk:

    • *_KEY=, *_TOKEN=, *_SECRET=, *PASSWORD= assignments, including Header: value and JSON forms

    • Authorization: Bearer … headers

    • credentials in URLs (postgres://user:pass@…)

    • --password / --token / --api-key / --secret flags

    • bare sk-…, ghp_…, github_pat_…, AKIA… and xox?-… tokens

    Redaction is a safety net, not a guarantee, so keep the file out of version control.

  • Owner-only, crash-safe writes. Files are written with mode 0600. Each save writes a temp file, fsyncs it, and renames it into place, so a crash mid-save can't leave a half-written checkpoint.

  • Automatic backup. The previous valid checkpoint is kept as .claude-checkpoint.prev. If the main file is corrupt, load falls back to the backup and says so. A corrupt file never overwrites a good backup.

  • Bounded size. Every field has a length cap, and the file is capped at 64 KB (the oldest commands are dropped first), so a checkpoint can't grow into a token sink.

  • No shell. Git runs through execFile with a 3-second timeout and GIT_OPTIONAL_LOCKS=0, so it never contends with your own git commands.

  • Doesn't touch your config. If the checkpoint isn't git-ignored, the save response warns you. It never edits .gitignore for you.

  • Safe with parallel tool calls. Tool calls are serialized inside the server, so concurrent merge saves can't lose updates.


Troubleshooting

Symptom

Fix

checkpoint doesn't appear in /mcp

Run claude mcp list and check that the path is absolute and dist/index.js exists (npm run build).

Checkpoint is written to the wrong directory

The server fell back to its working directory. Pass projectRoot, or set CHECKPOINT_PROJECT_ROOT.

projectRoot must be an absolute path

Use a full path such as /home/me/code/app, not ./app.

Brief says "Saved commit … is no longer reachable"

The branch was rebased or reset after the save. Drift can't be computed against history, so treat the flagged files as needing a re-read.

Warning: "not git-ignored"

Add .claude-checkpoint* to .gitignore.

No "Since this checkpoint" section

The project isn't a git repo, or had no commits at save time.

Server logs go to stderr. Stdout is reserved for the MCP protocol.


Development

npm run typecheck   # strict TypeScript, src + tests
npm test            # unit tests + in-memory MCP end-to-end tests (vitest)
npm run build       # compile to dist/
npm run inspect     # open the MCP Inspector against dist/index.js
src/
├── index.ts    # entry point: stdio transport, signals, stderr logging
├── server.ts   # McpServer construction + server instructions
├── tools.ts    # save/load tool schemas and handlers
├── schema.ts   # zod schema for the checkpoint file (v1) + migrations
├── store.ts    # project root resolution, atomic I/O, backup/fallback
├── git.ts      # branch/HEAD/status snapshot, blob hashing, drift detection
├── redact.ts   # secret scrubbing
└── render.ts   # checkpoint → markdown resume brief

Built with the official @modelcontextprotocol/sdk and zod.

License

MIT

Available Tools

2 tools
load_session_checkpointLoad session checkpointA
Read-onlyIdempotent

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
formatNobrief: compact markdown for resuming (recommended). full: the complete checkpoint JSON.brief
projectRootNoAbsolute path of the project. Defaults to the client's workspace root or the server's working directory.

Output Schema

ParametersJSON Schema
NameRequiredDescription
pathYes
driftNo
foundYes
warningsYes
updatedAtNo
checkpointNo
fromBackupNo

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond them by previewing the brief's contents and the "changed since saved" diff, though it says nothing about behavior when no checkpoint file exists.

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?

Two sentences, no filler: the first delivers the action and the return contract, the second delivers the trigger. Front-loaded with the verb so an agent grasps the purpose immediately.

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 the description need not re-explain return shape, and annotations cover the safety profile for a 2-parameter tool with zero required params. What remains — what it loads, what it returns at a glance, and when to call it — is all present.

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% and the format enum is fully documented in the schema itself (brief = compact markdown, full = complete JSON), so the schema does the heavy lifting. The description's mention of a "compact brief" aligns with the default but adds no syntax or format detail beyond the schema; baseline 3.

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 (Load) and resource (.claude-checkpoint file), then enumerates exactly what the returned brief contains: goal, progress, next steps, touched files, recent commands, and changed-since files. The opposite verb makes it trivially distinguishable from the save_session_checkpoint sibling without opening either schema.

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?

"Call at the start of a session or when the user asks to resume" is an explicit, actionable trigger condition. It does not name the save_session_checkpoint alternative or state when-not to call, but for a load-only read tool the trigger is clear enough.

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

save_session_checkpointSave 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
goalYesThe primary objective of the session, in one or two sentences.
modeNoreplace: overwrite the checkpoint. merge: update the existing one, appending commands, decisions and files.replace
tasksNoSub-goals with their status. In merge mode, tasks with the same description are updated.
summaryNoWhere things stand: what works, what is broken, what you were in the middle of.
decisionsNoKey decisions, constraints, and dead ends to avoid repeating.
nextStepsNoConcrete next actions, in order, for whoever resumes.
projectRootNoAbsolute path of the project. Defaults to the client's workspace root or the server's working directory.
modifiedFilesNoFiles you changed, with an optional note. Uncommitted git changes are detected automatically; list files here to annotate them or to include committed ones.
recentCommandsNoRecent significant terminal commands (builds, tests, migrations), oldest first, with exit codes and a short note on the outcome. Secrets are redacted automatically.

Output Schema

ParametersJSON Schema
NameRequiredDescription
modeYes
pathYes
bytesYes
countsYes
warningsYes

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedload_session_checkpoint
    • First observedsave_session_checkpoint

TDQS

A4.4/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    B
    quality
    A
    maintenance
    Basic Memory is a knowledge management system that allows you to build a persistent semantic graph from conversations with AI assistants. All knowledge is stored in standard Markdown files on your computer, giving you full control and ownership of your data. Integrates directly with Obsidan.md
    17
    7,290 PyPI
    4,248
    AGPL 3.0
  • A
    license
    Not graded
    quality
    B
    maintenance
    Provides persistent context management for Claude AI coding assistants, allowing you to save and restore conversation context, create checkpoints, and organize information across sessions to prevent losing important work history and decisions during long coding sessions.
    143 npm
    136
    MIT