Claude Infinite Context
Uses Google Gemini API as the primary AI provider for intelligent merging and compression of project context, enabling persistent long-term memory beyond Claude's 200k token limit
Stores compressed project state, checkpoint history, and session data using Redis Stack with RedisJSON module, implementing optimistic locking for concurrent access control
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Claude Infinite Contextsave my current project context before I clear the chat"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Claude Infinite Context
A Model Context Protocol (MCP) server that overcomes Claude Code's 200k token context limit by implementing persistent long-term memory using Redis and AI-powered state summarization.
Quick Start
# 1. Install Redis Stack
brew install redis-stack/redis-stack/redis-stack # macOS
redis-stack-server
# 2. Install the MCP server
git clone <repository-url> claude-infinite-context
cd claude-infinite-context
npm install
npm run build
# 3. Configure environment
cp .env.example .env
# Edit .env and add your GEMINI_API_KEY
# 4. Add to Claude Code config (~/.config/claude-code/config.json)
{
"mcpServers": {
"infinite-context": {
"command": "node",
"args": ["/absolute/path/to/claude-infinite-context/dist/index.js"],
"env": {
"GEMINI_API_KEY": "your-key-here",
"REDIS_URL": "redis://localhost:6379",
"PROJECT_ROOT": "${workspaceFolder}"
}
}
}
}
# 5. Verify installation
./test-basic.shGet API Keys: Google AI Studio (Gemini - required) | Anthropic Console (Claude - optional fallback)
Architecture
The Problem
Claude Code operates with a 200k token context window. Once you hit this limit, you need to run /clear which wipes all context, forcing you to start over. This system solves that problem.
The Solution: "Rolling Snowball" Memory
Instead of trying to store infinite conversation history (which would grow unbounded), this system uses a "Rolling Snowball" approach:
Working Memory (RAM): Your current 200k token context window in Claude Code
Long-Term State (Redis): A compressed project "brain" that persists across sessions
LLM-Based Merge: Uses Claude to intelligently merge old state + new context into an updated summary
Think of it like a developer's mental model of a project:
You don't remember every line of code you've ever written
You remember the architecture, recent changes, current task, and key decisions
This system does the same thing, automatically
Key Concepts
Checkpoint Before
/clear: Save your current context to RedisAI-Powered Summarization: Uses Google Gemini (with optional Claude fallback) to intelligently merge old state with new context, preserving what's important
Resume After
/clear: Load the compressed state back into your fresh contextOptimistic Locking: Prevents race conditions if multiple sessions run concurrently
Version History: Keep last 5 checkpoints for rollback
Installation
Prerequisites
Node.js 18+ (for ES modules support)
Redis Stack (not regular Redis - requires RedisJSON module)
Google Gemini API Key (required for AI-powered state merging)
Anthropic API Key (optional - used as fallback if Gemini fails)
Step 1: Install Redis Stack
Why Redis Stack? This project needs RedisJSON module for storing structured data. Regular Redis won't work.
Verify if you have it:
redis-cli JSON.GET test
# ✅ Returns (nil) → You have Redis Stack
# ❌ Returns ERR unknown command → Install Redis Stack belowmacOS (Homebrew):
brew tap redis-stack/redis-stack
brew install redis-stack
redis-stack-serverDocker:
docker run -d -p 6379:6379 --name redis-stack redis/redis-stack:latestLinux:
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list
sudo apt-get update
sudo apt-get install redis-stack-server
redis-stack-serverStep 2: Clone and Install the MCP Server
# Clone or download the repository
git clone <repository-url> claude-infinite-context
cd claude-infinite-context
# Install dependencies
npm install
# Build TypeScript to JavaScript
npm run buildStep 3: Verify Installation
./test-basic.sh
# Should show: ✅ All tests passed!Step 4: Configure Environment
cp .env.example .env
nano .envEdit .env and configure your API keys:
# Required: Google Gemini API Key
GEMINI_API_KEY="your-gemini-api-key-here"
# Optional: Anthropic API Key (fallback)
ANTHROPIC_API_KEY="sk-ant-your-key-here"
# Optional: Gemini Model (defaults to gemini-3-pro-preview)
GEMINI_MODEL="gemini-3-pro-preview"
# Redis connection (defaults shown)
REDIS_URL="redis://localhost:6379"Getting API Keys:
Gemini API Key: Get from Google AI Studio
Anthropic API Key: Get from Anthropic Console
Configuration
Add this to your ~/.config/claude-code/config.json:
{
"mcpServers": {
"infinite-context": {
"command": "node",
"args": ["/absolute/path/to/claude-infinite-context/dist/index.js"],
"env": {
"GEMINI_API_KEY": "your-gemini-api-key",
"ANTHROPIC_API_KEY": "sk-ant-...",
"GEMINI_MODEL": "gemini-3-pro-preview",
"REDIS_URL": "redis://localhost:6379",
"PROJECT_ROOT": "${workspaceFolder}"
}
}
}
}Important Configuration Notes:
Replace
/absolute/path/to/claude-infinite-contextwith the actual absolute path where you installed the serverGEMINI_API_KEYis required for AI-powered state mergingANTHROPIC_API_KEYis optional but recommended as a fallbackPROJECT_ROOTuses${workspaceFolder}which automatically resolves to your current project directoryAvailable Gemini models:
gemini-3-pro-preview(latest),gemini-2.5-pro(stable),gemini-2.5-flash(fast)
Usage
Typical Workflow
Start a new project
cd /your/project claude-codeThe MCP server automatically creates
.claude_session_idin your project root.Work normally until you approach token limit (~150k tokens)
Checkpoint before clearing
> Checkpoint my current work with context summaryClaude Code will call the
checkpointtool, which uses Gemini AI to intelligently merge your new context with the existing project state stored in Redis.Clear context
/clearThis clears Claude's working memory but your project state remains safely stored in Redis.
Resume from checkpoint
> Resume where we left offClaude Code will call the
resumetool to load your compressed project state, allowing you to continue seamlessly with full context of your previous work.
Available Tools
The MCP server exposes these tools to Claude:
checkpoint
Saves current context to Redis.
When to use: Before running /clear, or periodically during long sessions.
Example:
> I've made a lot of progress. Checkpoint this work before I clear context.Parameters:
context(string): Summary of recent work, decisions, active filestoken_count(number): Current token usage
resume
Loads the last checkpoint.
When to use: After running /clear, or when starting a new session.
Example:
> Resume where we left offReturns: Formatted project state with overview, architecture, current task, active files, recent changes, and pending decisions.
status
Shows current state metadata.
When to use: To check version, token usage, active files, or checkpoint history.
Example:
> Show me the infinite context statusReturns: Session ID, version, timestamps, token usage, active files, decisions, and checkpoint history.
rollback
Reverts to a previous checkpoint version.
When to use: If a merge produced incorrect results or you want to undo recent changes.
Example:
> Rollback to the previous checkpointParameters:
steps(number, default: 1): How many versions to roll back
Manual Testing
You can test the server manually:
# Start the server
npm run dev
# In another terminal, send a test request
echo '{"jsonrpc":"2.0","method":"tools/list","id":1}' | node dist/index.jsHow It Works
AI-Powered State Management
This system uses a dual-AI approach for intelligent context compression:
Why Gemini as Primary?
Gemini 3 Pro offers excellent performance at lower cost
Fast response times for state merging operations
Strong structured output capabilities (JSON generation)
Large context window for processing complex project states
Why Claude as Fallback?
Provides redundancy and reliability
Excellent at understanding code context and preserving technical details
High-quality JSON generation and instruction following
Ensures system continues working even if Gemini is unavailable
Intelligent Merge Process:
When you checkpoint your work, the system doesn't just dump everything into storage. Instead:
Context Analysis: The AI reads your old project state and new work context
Smart Compression: Identifies what's important vs. what can be safely compressed
Intelligent Merging: Combines new information with existing knowledge
Task Migration: Moves completed work from "current task" to "recent changes" history
File Tracking: Updates which files are actively being worked on
Decision Recording: Tracks architectural decisions and their outcomes
Result: You get a continuously updated "project memory" that preserves critical context while staying under token limits.
Data Schema
The project state stored in Redis has this structure:
{
meta: {
version: number, // Incremented on each update (optimistic locking)
last_checkpoint: string, // ISO timestamp
last_access: string, // ISO timestamp
session_id: string, // UUID from .claude_session_id
token_budget_used: number // Current token count
},
project_context: {
overview: string, // Max ~200 tokens
architecture: string, // Key architectural decisions
recent_changes: Array<{ // Ring buffer: last 10 changes
timestamp: string,
summary: string,
files: string[]
}>
},
active_context: {
current_task: string, // What's being worked on now
active_files: string[], // Currently relevant files
active_decisions: Array<{ // Pending or decided questions
question: string,
status: "pending" | "decided",
decision?: string
}>
}
}Optimistic Locking (Race Condition Prevention)
Uses Redis WATCH/MULTI/EXEC for atomic updates:
WATCHthe state keyRead current state
Apply transformation (merge with LLM)
Increment
versionfieldEXECtransactionIf another process modified the state during this time, transaction fails
Retry with exponential backoff (max 3 attempts)
This ensures that concurrent sessions don't overwrite each other's changes.
AI-Powered Summary Merger
When you checkpoint, the system uses AI to intelligently merge your context:
Read old state from Redis
Send both old state and new context to Gemini (or Claude as fallback) with a structured prompt
Receive updated JSON matching the project state schema
Validate with Zod schema validation
Verify data integrity (session_id preserved, no critical fields dropped)
Save to Redis with optimistic locking
AI Provider Selection:
Primary: Google Gemini (configurable model, default:
gemini-3-pro-preview)Fallback: Anthropic Claude (
claude-3-5-sonnet-20241022) if Gemini fails or is unavailableRetry Logic: Up to 2 retries with exponential backoff for transient failures
Ultimate Fallback: Simple append strategy if all AI providers fail
Merge Intelligence:
Preserves all critical data (session IDs, file paths, timestamps)
Moves completed tasks from active context to recent_changes history
Updates active_files based on files mentioned in new context
Maintains detailed, comprehensive summaries (not overly compressed)
Keeps ring buffer of last 10 recent changes
Updates decision status (pending → decided)
Returns only valid JSON matching the schema
Configuration:
Model: Change via
GEMINI_MODELenvironment variableTemperature: 0.3 (balanced creativity/consistency)
Max tokens: 8000 output tokens
Customizable in
src/core/SummaryMerger.ts
Session Management
Each project gets a .claude_session_id file containing a UUID. This:
Links the project directory to its Redis state
Allows multiple projects to coexist
Persists across
/clearcommandsEnables session locking (detects concurrent usage)
Checkpoint History
The last 5 checkpoint versions are stored in a Redis list:
Each entry includes: version, timestamp, merge duration, token count, full state
Allows rollback if a merge produces bad results
Helps debug issues (see what changed between versions)
Testing
Quick Verification
Run the automated test script:
./test-basic.shThis verifies:
Redis Stack is running with JSON module
Node.js version is compatible
Build completed successfully
MCP server starts and lists all 4 tools
All source files and dependencies are present
Manual Testing with Claude Code
After configuration:
mkdir -p /tmp/test-project
cd /tmp/test-project
claude-codeTest the workflow:
1. Show me the infinite context status
→ Should create .claude_session_id and show empty state
2. Create a test file called hello.js
→ Claude creates the file
3. Checkpoint this work
→ Should save to Redis: "Checkpoint saved successfully (version 1)"
4. /clear
→ Context cleared
5. Resume where we left off
→ Should load state with hello.js mentioned
6. What files are we working on?
→ Claude should remember hello.js without reading it againVerify in Redis
# List all project states
redis-cli KEYS "project:*"
# View your project's state
redis-cli JSON.GET project:state:<session-id>
# View checkpoint history
redis-cli LRANGE project:history:<session-id> 0 -1Troubleshooting
"ERR unknown command 'JSON.GET'"
Cause: You're running regular Redis instead of Redis Stack.
Fix:
# Stop regular Redis
brew services stop redis # macOS
# or
sudo systemctl stop redis # Linux
# Install and start Redis Stack
brew install redis-stack/redis-stack/redis-stack # macOS
redis-stack-server
# Or use Docker
docker run -d -p 6379:6379 redis/redis-stack:latestVerify:
redis-cli JSON.GET test
# Should return: (nil)
# NOT: ERR unknown command"Failed to connect to Redis"
Cause: Redis Stack isn't running.
Fix:
# macOS
redis-stack-server
# Docker
docker start redis-stack
# Or create new:
docker run -d -p 6379:6379 --name redis-stack redis/redis-stack:latest"Session already locked by another process"
Cause: Another Claude Code session is using the same project.
Fix: Close the other session, or wait 5 minutes for the lock to expire. The server will proceed with a warning.
"Invalid project state schema"
Cause: Redis data is corrupted or from an incompatible version.
Fix: Delete the state and start fresh:
redis-cli
> DEL project:state:<your-session-id>
> DEL project:history:<your-session-id>"AI merge failed" or "LLM merge failed"
Cause: Network issue, API error, invalid API key, or the AI returned invalid JSON.
Fix: The system automatically retries and falls back through these strategies:
Retry with exponential backoff (up to 2 retries)
If Gemini fails, try Anthropic (if API key configured)
If all AI providers fail, use simple append strategy
Debugging: Check logs for detailed error information:
LOG_LEVEL=DEBUG npm run dev # Verbose logging to consoleCommon causes:
Invalid or expired API keys
Network connectivity issues
API rate limiting
Insufficient API credits
Token usage still grows over time
Expected behavior: The checkpoint compresses context, but Claude still needs to read the full state on resume. If you notice the state itself growing too large:
Check
statusto see state sizeConsider manually editing overview/architecture to be more concise
Old completed decisions can be removed from
active_decisions
Files in active_files no longer exist
Handled automatically: The system validates files on checkpoint and resume, filtering out missing files. Orphaned files are logged as warnings.
Best Practices
When to Checkpoint
Good times to checkpoint:
Before running
/clearwhen approaching 150k+ tokensAfter completing a major feature or refactoring
Before switching to a different task or codebase area
At the end of a work session
After making important architectural decisions
Avoid checkpointing:
Too frequently (increases API costs unnecessarily)
With minimal context (wait until you have substantial new work to save)
In the middle of debugging sessions (checkpoint after fixing the issue)
Optimizing State Size
Keep your project state efficient by:
Regular cleanup: Periodically review
statusand ensure old, irrelevant information is being naturally prunedFocused context: When checkpointing, provide concise but complete context summaries
Let AI work: The system is designed to automatically compress and prioritize information
Monitor growth: If state exceeds ~10k tokens consistently, consider what information might be redundant
Multi-Project Workflow
When working on multiple projects:
# Each project gets its own session
cd /path/to/project-a
claude-code # Creates unique .claude_session_id
cd /path/to/project-b
claude-code # Creates different .claude_session_idSessions are isolated - checkpoints in one project don't affect others.
API Cost Management
To minimize API costs:
Checkpoint strategically: Don't checkpoint trivial changes
Use Gemini: It's the default and more cost-effective than Anthropic
Monitor usage: Check your API dashboard periodically
Consider model selection:
gemini-2.5-flashis faster and cheaper thangemini-3-pro-previewbut may be less accurate
Development
Project Structure
claude-infinite-context/
├── src/
│ ├── index.ts # MCP server entry point
│ ├── config/
│ │ └── env.ts # Environment configuration with Zod validation
│ ├── core/
│ │ ├── ProjectBrain.ts # Main orchestrator for state management
│ │ ├── RedisClient.ts # Redis client with optimistic locking
│ │ └── SummaryMerger.ts # AI-based merge logic (Gemini + Claude)
│ ├── types/
│ │ └── schema.ts # Zod schemas + TypeScript types
│ └── utils/
│ ├── sessionId.ts # .claude_session_id file management
│ ├── validation.ts # File path validation
│ ├── time.ts # Timestamp utilities
│ └── logger.ts # Structured JSON logging
├── dist/ # Compiled JavaScript (generated by build)
├── node_modules/ # Dependencies (generated by npm install)
├── package.json # Dependencies and scripts
├── tsconfig.json # TypeScript configuration
├── .env.example # Environment variable template
├── .env # Your local environment (gitignored)
├── test-basic.sh # Installation verification script
└── README.md # This documentationScripts
npm run dev # Run with auto-reload (tsx watch)
npm run build # Compile TypeScript to dist/
npm run start # Run compiled version
npm test # Run tests (if configured)Logging
Set LOG_LEVEL=DEBUG in .env for verbose logging:
LOG_LEVEL=DEBUG npm run devLogs are structured JSON for easy parsing:
{"timestamp":"2025-01-27T10:30:00.000Z","level":"INFO","message":"Checkpoint completed","data":{"version":5,"duration":1234}}Advanced Usage
Multiple Projects
Each project gets its own session ID. You can work on multiple projects simultaneously:
cd /project-a
claude-code # Creates .claude_session_id with UUID-A
cd /project-b
claude-code # Creates .claude_session_id with UUID-BRedis stores state separately:
project:state:UUID-Aproject:state:UUID-B
Manual State Inspection
redis-cli
# List all project states
> KEYS project:state:*
# View a specific state
> JSON.GET project:state:<session-id>
# View checkpoint history
> LRANGE project:history:<session-id> 0 -1Backing Up State
# Export state to file
redis-cli JSON.GET project:state:<session-id> > backup.json
# Restore from file
redis-cli JSON.SET project:state:<session-id> $ "$(cat backup.json)"Customizing AI Behavior
The AI-powered merge can be customized by editing src/core/SummaryMerger.ts:
Model Configuration:
const DEFAULT_GEMINI_MODEL = 'gemini-3-pro-preview'; // Primary model
const ANTHROPIC_MODEL = 'claude-3-5-sonnet-20241022'; // Fallback modelGeneration Parameters:
const MAX_TOKENS = 8000; // Maximum output tokens
const TEMPERATURE = 0.3; // Creativity vs consistency (0.0-1.0)Provider Selection:
You can prefer Anthropic over Gemini by modifying the merge() method call in ProjectBrain.ts:
// Use Anthropic as primary
await this.merger.merge(oldState, context, tokenCount, 'anthropic');
// Use Gemini as primary (default)
await this.merger.merge(oldState, context, tokenCount, 'gemini');Prompt Engineering:
Edit the buildMergePrompt() method to customize how the AI processes your context. The prompt includes schema definitions, preservation rules, and output format requirements.
Limitations
State size: The compressed state should ideally stay under ~10k tokens. If it grows significantly larger, checkpoint and resume operations become less efficient and may consume more of your context budget.
AI accuracy: The merge quality depends on the AI model's ability to accurately summarize and preserve important information. Periodically review your state using the
statustool to ensure critical information isn't being lost.Session locking: If you force-quit Claude Code, the session lock may persist for up to 5 minutes. Either wait for the lock to expire or manually delete it:
redis-cli DEL project:lock:<session-id>Not a backup system: This system stores state in Redis, which is primarily an in-memory database. If Redis crashes or restarts without persistence enabled, your state may be lost. For production use, enable Redis persistence with
redis-cli CONFIG SET save "900 1 300 10"or useredis-cli SAVEto manually persist to disk.API dependencies: The system requires working API access to either Gemini or Anthropic. Network issues or API outages will trigger the fallback mechanisms, ultimately falling back to simple append strategy if all AI providers fail.
Token costs: Each checkpoint operation calls the Gemini API (or Anthropic as fallback), which incurs API usage costs. For large projects with frequent checkpoints, monitor your API usage.
License
MIT
Contributing
Contributions are welcome! Please feel free to submit issues and pull requests to the project repository.
Before contributing:
Ensure all tests pass with
./test-basic.shFollow the existing TypeScript code style
Update documentation for any API or configuration changes
Test with both Gemini and Anthropic providers
Technology Stack
Runtime: Node.js 18+ with ES modules
Language: TypeScript 5.7+
MCP SDK: @modelcontextprotocol/sdk v1.0.4
Database: Redis Stack (with RedisJSON module)
AI Providers:
Google Gemini API (@google/generative-ai)
Anthropic Claude API (@anthropic-ai/sdk)
Validation: Zod for schema validation
Testing: Vitest
Credits
Built for use with Claude Code, Anthropic's official CLI tool for Claude AI.
Powered by:
Model Context Protocol (MCP) - Anthropic's protocol for AI-app integrations
Google Gemini - Primary AI provider for intelligent state merging
Anthropic Claude - Fallback AI provider and the assistant you're interfacing with
Redis Stack - In-memory database with JSON support
Available Tools
4 toolscheckpointA
Save current context to Redis before running /clear. Merges new context with existing project state using LLM-based summarization.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | The current work context to checkpoint (summary of recent work, decisions, files) | |
| token_count | Yes | Current token budget usage |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the action ('Save'), storage location ('Redis'), and method ('Merges new context with existing project state using LLM-based summarization'), which covers key behavioral aspects. However, it lacks details on permissions, error conditions, or what happens if the merge fails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose, usage context, and method. Every word earns its place with no redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involving Redis storage and LLM summarization), no annotations, and no output schema, the description is adequate but has gaps. It explains what the tool does but doesn't cover return values, error handling, or dependencies, which could be important for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents both parameters fully. The description adds no additional meaning about the parameters beyond what the schema provides, such as format examples or usage tips. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Save current context to Redis') and resource ('context'), while distinguishing it from sibling tools by mentioning '/clear' and the summarization method. It goes beyond the tool name 'checkpoint' to explain what is being checkpointed and how.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('before running /clear'), which implies it's a preparatory step for clearing operations. However, it doesn't explicitly mention when not to use it or name alternatives among the sibling tools (resume, rollback, status).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resumeB
Load the last checkpoint at session start. Returns formatted context to inject into the conversation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool loads a checkpoint and returns formatted context, but lacks details on behavioral traits like error handling (e.g., what happens if no checkpoint exists), side effects, or performance considerations. The description adds some value by specifying the return action, but it's insufficient for a tool with potential state implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: two sentences that directly state the tool's action and outcome without waste. Every sentence earns its place by providing essential information, and there is no redundant or verbose content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (state-related with no annotations and no output schema), the description is minimally adequate. It explains what the tool does and its return purpose, but lacks details on the formatted context's structure, error cases, or interaction with siblings like 'checkpoint'. Without annotations or output schema, more behavioral context would improve completeness for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter information, which is appropriate. Baseline for 0 parameters is 4, as the description need not compensate for any gaps, and it correctly avoids unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Load the last checkpoint at session start' specifies the action (load) and resource (last checkpoint), with context about when it operates (session start). It distinguishes from siblings like 'checkpoint' (create) and 'rollback' (revert), though not explicitly. However, it lacks full sibling differentiation, such as contrasting with 'status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: 'at session start' suggests when to use this tool, likely for initialization or recovery. However, it does not provide explicit guidance on when not to use it or alternatives, such as whether to use 'rollback' for different recovery scenarios. No misleading information is present, but the guidance is limited to implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rollbackB
Revert to a previous checkpoint version. Useful if a merge produced incorrect results.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | No | Number of versions to roll back (default: 1) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions the tool is 'useful if a merge produced incorrect results,' implying it's a corrective action, but fails to disclose critical behavioral traits such as whether the rollback is destructive, irreversible, requires specific permissions, or has side effects on related data. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a usage hint. It's efficient with minimal waste, though the second sentence could be more integrated for a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with potential data impact), no annotations, and no output schema, the description is incomplete. It lacks details on behavior, outcomes, error conditions, or what 'revert' entails, leaving the agent with insufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'steps' clearly documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as explaining what 'versions' refer to or constraints on 'steps.' Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('revert') and target ('previous checkpoint version'), distinguishing it from siblings like 'checkpoint' (create) and 'resume' (continue). However, it doesn't explicitly specify what resource is being reverted (e.g., data, state, or process), leaving some ambiguity compared to a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context ('if a merge produced incorrect results'), suggesting when to use it. However, it lacks explicit guidance on when not to use it or alternatives (e.g., vs. 'resume' or manual correction), and doesn't mention prerequisites like needing an existing checkpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
statusA
Show current state metadata including version, active files, tasks, token usage, and checkpoint history.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly indicates this is a read-only operation ('Show') and specifies what information will be returned, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, or how frequently the state updates. The description adds value by listing the metadata components but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Show current state metadata') followed by specific examples. Every word earns its place by either stating the action or enumerating the metadata components without unnecessary elaboration or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's zero-parameter simplicity and lack of both annotations and output schema, the description provides adequate but minimal context. It tells what information will be shown but doesn't explain format, structure, or potential limitations of the returned metadata. For a status monitoring tool with no structured output definition, more detail about the return values would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on what the tool returns. No parameter information is needed or provided beyond what the schema already indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Show') and the comprehensive scope of resources ('current state metadata including version, active files, tasks, token usage, and checkpoint history'). It effectively distinguishes from siblings like checkpoint, resume, and rollback by focusing on read-only status display rather than state manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the listed metadata items, suggesting it's for monitoring system state. However, it doesn't explicitly state when to use this tool versus alternatives like checking specific resources individually, nor does it mention any prerequisites or exclusions for usage.
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. Dates show when Glama detected each change.
4 tool updates
- First observed
checkpoint - First observed
resume - First observed
rollback - First observed
status
TDQS
Each tool has a clearly distinct purpose: checkpoint saves context, resume loads it, rollback reverts to a previous version, and status shows metadata. There is no overlap or ambiguity between these operations, making tool selection straightforward for an agent.
All tool names follow a consistent, simple verb-based pattern (checkpoint, resume, rollback, status) without any mixing of conventions like snake_case or camelCase. This uniformity enhances readability and predictability across the tool set.
With 4 tools, the server is well-scoped for managing context checkpoints in a session. Each tool serves a specific, essential function in the lifecycle (save, load, revert, inspect), and there are no extraneous or missing tools for this focused purpose.
The tool set provides complete coverage for the context management domain: checkpoint (create), resume (read), rollback (update/revert), and status (monitor). There are no obvious gaps, as all core operations for saving, restoring, and tracking context states are included.
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Persistent, outcome-grounded episodic memory for Claude. 14ms CPU retrieval, no GPU, no vector DB.
Project memory, semantic code search, and grounded agent context.
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/coderdeep11/claude-memory-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server