Context Travel MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLAUDE_SESSION_ID | No | Explicit session ID | |
| CLAUDE_PROJECTS_DIR | No | Override projects directory | ~/.claude/projects |
| CLAUDE_CHECKPOINTS_DIR | No | Override checkpoints directory | ~/.claude/checkpoints |
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| checkpoint_contextA | Save your current context state as a named checkpoint. Use this when you're well-oriented and want to be able to return to this mental state later. Good moments to checkpoint:
The checkpoint captures your entire conversation history up to this point. |
| reset_to_checkpointA | Reset your context back to a saved checkpoint, injecting a handoff message to your future self. The message_to_self will appear as if you wrote it just before the reset. Use it to brief your future self on:
After calling this, your context will be restored to the checkpoint state plus your handoff message. |
| list_checkpointsB | List all available checkpoints for the current session. Shows when each was created and any notes attached. |
| get_context_statsA | Get statistics about your current context window health. Returns:
Use this to decide when you might want to checkpoint or reset. |
| delete_checkpointC | Delete a checkpoint you no longer need. |
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 5 tools
Each tool has a distinct and non-overlapping purpose: checkpoint_context saves context, delete_checkpoint removes it, get_context_stats provides metrics, list_checkpoints enumerates saved states, and reset_to_checkpoint restores to a checkpoint. There is no ambiguity in tool selection.
All tools follow a consistent verb_noun pattern (e.g., checkpoint_context, delete_checkpoint, get_context_stats, list_checkpoints, reset_to_checkpoint). The naming is uniform and predictable across the set.
With 5 tools, the server is well-scoped for managing context checkpoints, covering creation, deletion, listing, restoration, and monitoring. Each tool earns its place without being excessive or insufficient.
The tool set provides complete lifecycle coverage for context checkpoint management: create (checkpoint_context), read (list_checkpoints, get_context_stats), update (reset_to_checkpoint), and delete (delete_checkpoint). There are no obvious gaps for the domain.