session-checkpoint-mcp

Overview Schema Source Related Servers Discussions Admin

Load session checkpoint

load_session_checkpoint

Read-onlyIdempotent

Loads a saved checkpoint and returns a compact resume brief with goal, progress, next steps, touched files, recent commands, and changed files to resume work after crashes, resets, or context loss.

Instructions

Load this session's checkpoint and return a compact brief of its 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. If this session has no checkpoint but others exist in the project, it returns a list instead: show it to the user, ask which one to resume, and call again with checkpoint set to its selector.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "load_session_checkpoint"
  }
}

Input Schema

Name	Required	Description	Default
`format`	No	brief: compact markdown for resuming (recommended). full: the complete checkpoint JSON.	brief
`checkpoint`	No	Which checkpoint to load, as a selector from list_session_checkpoints: a session id, or 'legacy'. Omit to load this session's own checkpoint.
`projectRoot`	No	Absolute path of the project. Defaults to the client's workspace root or the server's working directory.

Output Schema

Name	Required	Description	Default
`path`	Yes
`text`	No
`brief`	No
`drift`	No
`found`	Yes
`total`	No
`omitted`	No
`selector`	No
`warnings`	Yes
`updatedAt`	No
`candidates`	No
`checkpoint`	No
`fromBackup`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.3Nov 7, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds behavior the annotations cannot: the two output modes (compact brief vs. full JSON), the inclusion of a diff of files changed since save, and the important non-obvious branch where a list of other checkpoints is returned instead of a brief. Error conditions and any cost/latency characteristics are not mentioned.

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?

Front-loaded with what the tool returns, followed by when to call it and then the exception path. Three sentences, each carrying distinct operational information, with no restatement of the title or filler.

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, yet the description still gives a useful summary of the brief's contents, and it covers the conditional list-return path an agent would otherwise be surprised by. For a zero-required-parameter read tool with full schema coverage and annotations, nothing needed for correct invocation is missing.

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 a baseline of 3 would already apply. The description goes further by tying the `checkpoint` parameter to its real semantics — a selector obtained from the returned list, used when this session has no checkpoint of its own — which is the one parameter whose usage is not obvious from the schema alone.

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 and resource ('Load this session's checkpoint') and immediately enumerates what comes back: goal, progress, next steps, touched files, recent commands, and files changed since save. It is clearly distinguishable from save_session_checkpoint and list_session_checkpoints by the fallback clause describing when a list is returned instead of a brief.

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 explicit trigger conditions ('Call at the start of a session or when the user asks to resume') and a concrete recovery flow when no checkpoint exists: show the list, ask the user, re-call with the `checkpoint` selector. It stops short of naming the sibling tools (save_session_checkpoint, list_session_checkpoints) or stating when not to use this tool, so it is strong but not fully exhaustive.

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

Deploy Server