The Claude Historian server enables efficient search and analysis of Claude Code conversation history to find past solutions, track changes, and understand usage patterns.
Search Conversations: Find relevant conversations by query with optional project and timeframe filters
Find File Context: Retrieve conversations related to specific file paths
Find Similar Queries: Locate previous questions similar to a given query
Get Error Solutions: Discover how similar errors were resolved in past conversations
List Recent Sessions: View recent conversation sessions
Extract Compact Summary: Obtain a summary of a specific conversation session
Analyze Tool Patterns: Identify successful patterns of tool usage to improve workflows
Provides access to historical Docker configuration solutions and authentication troubleshooting
Enables finding information about Git operations during feature branch management and historical changes
Allows retrieving historical solutions for Kubernetes deployment issues and container crashes
Enables searching for past React-related solutions including infinite re-render loops and state management approaches
Provides access to historical solutions for Redis connection pooling problems
Allows finding historical discussions on state management comparing Redux with alternatives
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 Historian search for how we fixed the Docker auth issue last week"
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.
An Model Context Protocol (MCP) server for searching your Claude Code conversation history. Find past solutions, track file changes, and learn from previous work.
Requirements:
From shell:
claude mcp add claude-historian-mcp -- npx claude-historian-mcpFrom inside Claude (restart required):
Add this to our global mcp config: npx claude-historian-mcp
Install this mcp: https://github.com/Vvkmnn/claude-historian-mcpFrom any manually configurable mcp.json: (Cursor, Windsurf, etc.)
{
"mcpServers": {
"claude-historian-mcp": {
"command": "npx",
"args": ["claude-historian-mcp"],
"env": {}
}
}
}There is no npm install required -- no external dependencies or local databases, only search algorithms.
However, if npx resolves the wrong package, you can force resolution with:
npm install -g claude-historian-mcprenamed: This project was renamed from
claude-historiantoclaude-historian-mcp. Existing users should update your install command and MCP config args toclaude-historian-mcp.
Related MCP server: cc-session-search
Optionally, install the skill to teach Claude when to proactively use historian:
npx skills add Vvkmnn/claude-historian-mcp --skill claude-historian --global
# Optional: add --yes to skip interactive prompt and install to all agentsThis makes Claude automatically check your history before web searches, when encountering errors, or at session start. The MCP works without the skill, but the skill improves discoverability.
For automatic history search with hooks and commands, install from the claude-emporium marketplace:
/plugin marketplace add Vvkmnn/claude-emporium
/plugin install claude-historian@claude-emporiumThe claude-historian plugin provides:
Hooks (targeted, zero overhead on success):
Before WebSearch/WebFetch → Check search scope="similar"
Before EnterPlanMode → Check search scope="plans"
Before Task agents → Check search scope="tools"
After Bash errors → Check search scope="errors"
Command: /historian-search <query>
Requires the MCP server installed first. See the emporium for other Claude Code plugins and MCPs.
MCP server that gives Claude access to your conversation history. Two tools, 11 scopes, zero dependencies.
Runs locally (with cool shades [⌐■_■] 📜):
searchSearch across conversations, files, errors, plans, config, tasks, sessions, tools, similar queries, and memories.
search query="docker auth error" # default scope: all
search query="fix build" scope="conversations" # past solutions
search query="ENOENT" scope="errors" # error patterns + fixes
search query="auth" scope="plans" # implementation plans
search query="hooks" scope="config" # rules, skills, CLAUDE.md
search query="git push" scope="similar" # related questions asked before
search query="Edit" scope="tools" # tool usage workflows
search filepath="package.json" scope="files" # file change history
search scope="sessions" # recent sessions
search scope="memories" # project memory files
search query="deploy" scope="all" detail_level="detailed" # full context
search query="auth" timeframe="7d" project="my-app" # filtered📜 ── search "docker auth" ── 5 results · 405 tokens
{
"results": [{
"type": "assistant",
"ts": "2h ago",
"content": "Fixed Docker auth by updating registry credentials...",
"project": "my-app",
"score": 100,
"ctx": { "filesReferenced": ["docker-compose.yml"], "toolsUsed": ["Edit", "Bash"] }
}]
}📜 ── files "package.json" ── 92 operations · 1594 tokens
{
"filepath": "package.json",
"operations": [{
"type": "edit",
"ts": "1d ago",
"changes": ["Changed: \"version\": \"1.0.3\" → \"version\": \"1.0.4\""],
"content": "Updated version for release"
}]
}📜 ── tools "Bash" ── 5 patterns · 427 tokens
{
"tool": "Bash",
"patterns": [{
"name": "Bash",
"uses": 10,
"workflow": "$ npm run build 2>&1",
"practice": "Used with: ts, js, json, md files"
}]
}inspectGet an intelligent summary of any session by ID (full UUID or short prefix).
inspect session_id="latest" # most recent session
inspect session_id="d537af65" # short prefix works
inspect session_id="d537af65" focus="files" # only file changes
inspect session_id="d537af65" focus="tools" # only tool usage
inspect session_id="d537af65" focus="solutions" # only solutions📜 ── inspect my-app (68d5323b)
{
"session": {
"id": "68d5323b",
"ts": "2h ago",
"duration": 45,
"messages": 128,
"project": "my-app",
"tools": ["Edit", "Bash", "Read"],
"files": ["src/auth.ts", "package.json"],
"accomplishments": ["fixed auth bug", "added unit tests"],
"decisions": ["chose JWT over sessions"]
}
}How claude-historian-mcp works:
"docker auth" query
|
├─> Parallel Processing (search.ts:174): 15 projects × 10 files concurrently
| • Promise.allSettled for 6x speed improvement
| • Early termination when sufficient results found
| • Enhanced file coverage with comprehensive patterns
|
├─> Enhanced Classification (search.ts:642): implementation → boost tool workflows
| • Workflow detection for tool sequences (Edit → Read → Bash)
| • Semantic boundary preservation (never truncate mid-function)
| • Claude-optimized formatting with rich metadata
|
├─> Smart Ranking (utils.ts:267):
| ├─> Core Terms (scoring-constants.ts): "docker" +10, "auth" +10
| ├─> Supporting Terms: context words +3 each
| ├─> Tool Usage: Edit/Bash references +5
| ├─> File References: paths/extensions +3
| └─> Project Match: current project +5
|
├─> Results sorted by composite score:
| • "Edit workflow (7x successful)" (2h ago) ***** [score: 45]
| • "Docker auth with context paths" (yesterday) **** [score: 38]
| • "Container debugging patterns" (last week) *** [score: 22]
|
└─> Return Claude Code optimized resultsCore optimizations:
parallel processing: Promise.allSettled for 6x speed improvement across projects and files
workflow detection: Captures tool sequences like "Edit → Read → Bash" patterns
enhanced file matching: Comprehensive path variations with case-insensitive matching
intelligent deduplication: Content-based deduplication preserving highest-scoring results
intelligent truncation: Never truncates mid-function or mid-error
Claude-optimized formatting: Rich metadata with technical content prioritization
Search strategies:
JSON streaming parser (parseJsonlFile): Reads Claude Code conversation files on-demand without full deserialization
LRU caching (messageCache): In-memory cache with intelligent eviction for frequently accessed conversations
TF-IDF inspired scoring (calculateRelevanceScore): Term frequency scoring with document frequency weighting for relevance
Query classification (classifyQueryType): Naive Bayes-style classification (error/implementation/analysis/general) with adaptive limits
Edit distance (calculateQuerySimilarity): Fuzzy matching for technical terms and typo tolerance
Exponential time decay (getTimeRangeFilter): Recent messages weighted higher with configurable half-life
Parallel file processing (getErrorSolutions): Concurrent project scanning with early termination for 0.8s response times
Workflow pattern recognition (getToolPatterns): Detects tool usage sequences and related workflows for learning
Enhanced file context (findFileContext): Multi-project search with comprehensive path matching
Content-aware truncation (smartTruncation): Intelligent content boundaries over arbitrary character limits
Technical content prioritization (BeautifulFormatter): Code blocks, errors, and file paths get full preservation
Query similarity clustering (findSimilarQueries): Semantic expansion and pattern grouping for related questions
Design principles:
Universal engine -- single search backend for all Claude Code conversations
Parallel processing -- concurrent file scanning across session directories
Semantic expansion -- query synonyms and related terms for better recall
Zero dependencies -- only @modelcontextprotocol/sdk, no databases required
Offline -- never leaves your machine, scans local JSONL files only
File access:
Reads from: ~/.claude/conversations/
Zero persistent storage or indexing
Never leaves your machine
Performance: See PERFORMANCE.md for benchmarks, optimization history, and quality scores.
Every conversation history tool either loads context always (burning tokens when unused) or requires external runtimes and databases. Historian searches on-demand with zero dependencies.
Feature | historian | Claude Memory | claude-mem | deja | conversation-search |
Dependencies | Zero | Built-in | Bun + Python + SQLite + Chroma | Python | Rust toolchain |
Background service | No | No | Yes (port 37777) | No | No |
Writes to disk | Never | Yes (auto-memory files) | Yes (SQLite + Chroma DB) | Yes (breadcrumbs) | Yes (~10% index overhead) |
Session startup | 0 tokens | ~200 lines loaded | 5-8k tokens every session | Skill prompt loaded | 0 tokens |
Token cost (idle) | 0 | 200 lines/session | 5-8k/session | Skill prompt/session | 0 |
Search algorithms | None (file read) | Vector + keyword | Weighted signals | BM25 full-text | |
Fuzzy matching | Yes | No | Yes (vector similarity) | No | No |
Workflow detection | Yes | No | No | No | No |
Raw conversations | Yes | No (summaries only) | No (compressed observations) | Yes | Yes (filtered) |
Maintenance | Zero | Zero | Worker daemons, migrations | Skill config | Index rebuilds |
Claude Memory -- Claude's built-in memory (CLAUDE.md + auto-memory). Persists project rules and preferences across sessions. Forward-looking ("always use ESM imports"); not conversation search. Complementary: memory for rules, historian for past solutions.
claude-mem -- Plugin that captures observations via lifecycle hooks, compresses them into SQLite + Chroma, and loads context every session. Requires Bun, Python, and a background worker on port 37777. Real-world testing (270+ sessions): 95% of sessions never query history -- always-on tools pay 5-8k tokens per session regardless. Historian pays 0 tokens idle, 500-2k per query, saving ~475k tokens over 100 sessions. Known issues: creates stub session files that break --continue, worker daemon version conflicts, security hooks blocking valid edits.
deja -- Python skill that indexes sessions by episodes and accomplishments. Uses weighted signal ranking (todos > files > text). Requires Python and TodoWrite integration.
conversation-search -- Rust MCP server using Tantivy BM25 full-text search. Fast indexing (~1000 conversations/second) but requires Rust toolchain and persistent disk index.
Note: Claude Desktop stores conversations server-side, not locally. The local LevelDB files (~/Library/Application Support/Claude/) contain only session tokens, UI preferences, and Intercom state - not conversation content. Claude Desktop support is also blocked by LevelDB locks and Electron sandboxing.
This means local history search for Claude Desktop is not currently possible. This project focuses on Claude Code, which stores full conversation history locally in ~/.claude/projects/.
You may get some Claude Desktop from Claude Code, but only when the Claude app is closed. Furthermore A DXT package and build is available for future compatibility; further investigations are ongoing. Feel free to test with it.
git clone https://github.com/Vvkmnn/claude-historian-mcp && cd claude-historian-mcp
npm install && npm run build
npm testPackage requirements:
Node.js: >=20.0.0 (ES modules)
Runtime: @modelcontextprotocol/sdk
Zero external databases -- works with npx
Development workflow:
npm run build # TypeScript compilation with executable permissions
npm run dev # Watch mode with tsc --watch
npm run start # Run the MCP server directly
npm run lint # ESLint code quality checks
npm run lint:fix # Auto-fix linting issues
npm run format # Prettier formatting (src/)
npm run format:check # Check formatting without changes
npm run typecheck # TypeScript validation without emit
npm run test # Lint + type check
npm run prepublishOnly # Pre-publish validation (build + lint + format:check)Git hooks (via Husky):
pre-commit: Auto-formats staged .ts files with Prettier and ESLint
pre-push: Runs full validation (format, lint, type-check, build) before push
Contributing:
Fork the repository and create feature branches
Test with large conversation histories before submitting PRs
Follow TypeScript strict mode and MCP protocol standards
Learn from examples:
Official MCP servers for reference implementations
TypeScript SDK for best practices
Creating Node.js modules for npm package development
Appius Claudius Caecus in the Senate by Cesare Maccari (1888). Roman statesman and father of Latin prose.
Get intelligent summary of a conversation session with key insights
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session ID to summarize | |
| max_messages | No | Maximum messages to analyze (default: 10) | |
| focus | No | Focus area: solutions, tools, files, or all | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'intelligent summary' and 'key insights', which hints at analysis behavior, but it doesn't describe critical traits like whether this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like. For a tool with no annotations, this is a significant gap in transparency.
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 ('Get intelligent summary of a conversation session') and adds a clarifying detail ('with key insights'). There is no wasted verbiage, and it is appropriately sized for the tool's complexity.
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 moderate complexity (3 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral context, usage guidelines, and details on output format, which are crucial for an agent to use the tool effectively. The high schema coverage helps, but the description doesn't compensate for other gaps.
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%, meaning all parameters are documented in the schema. The description adds no additional semantic information about the parameters beyond what the schema provides, such as explaining the 'focus' options in more detail or giving examples. Thus, it meets the baseline score without compensating further.
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 with a specific verb ('Get') and resource ('summary of a conversation session'), and it adds value by specifying 'intelligent summary' and 'key insights'. However, it doesn't explicitly differentiate this from sibling tools like 'search_conversations' or 'list_recent_sessions', which might also involve conversation analysis, so it doesn't reach the highest score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_conversations' or 'list_recent_sessions', nor does it specify contexts or exclusions for usage. This leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all conversations and changes related to a specific file
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes | File path to search for in conversation history | |
| operation_type | No | Filter by operation: read, edit, create, or all | all |
| limit | No | Maximum number of results (default: 15) | |
| detail_level | No | Response detail: summary (default), detailed, raw | summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'find all conversations and changes,' implying a read-only operation, but doesn't specify permissions, rate limits, data sources, or response format. For a tool with 4 parameters and no output schema, this leaves significant gaps in understanding how it behaves.
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: 'Find all conversations and changes related to a specific file.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity.
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 has 4 parameters with 100% schema coverage but no annotations and no output schema, the description is minimally adequate. It states the purpose clearly but lacks behavioral context, usage guidance, and output details. For a search tool with moderate complexity, it should do more to compensate for the missing structured data.
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%, so the schema already documents all parameters thoroughly. The description doesn't add any meaning beyond what the schema provides—it doesn't explain parameter interactions, default behaviors, or practical examples. With high schema coverage, the baseline score of 3 is appropriate.
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: 'Find all conversations and changes related to a specific file.' It specifies the verb ('find'), resource ('conversations and changes'), and target ('specific file'). However, it doesn't explicitly differentiate from sibling tools like 'search_conversations' or 'list_recent_sessions', which might have overlapping functionality.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_conversations' or 'list_recent_sessions', nor does it specify prerequisites, exclusions, or contextual triggers for usage. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find previous similar questions or queries with enhanced matching
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Query to find similar previous questions | |
| limit | No | Maximum number of results (default: 8) | |
| detail_level | No | Response detail: summary (default), detailed, raw | summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'enhanced matching' but doesn't explain what this means operationally—how similarity is determined, what data sources are searched, whether results are ranked, or what the output format looks like. This leaves significant gaps for a search 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 a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core purpose.
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 moderate complexity (search with similarity matching), no annotations, and no output schema, the description is minimally adequate but incomplete. It covers the basic purpose but lacks details on behavior, output format, and usage context that would help an agent invoke 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?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional meaning about parameters beyond what's in the schema, meeting the baseline for high 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 tool's purpose: 'Find previous similar questions or queries with enhanced matching'. It specifies the verb ('Find') and resource ('previous similar questions or queries'), but doesn't differentiate from siblings like 'search_conversations' or 'get_error_solutions' which might have overlapping functionality.
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?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention sibling tools like 'search_conversations' or 'get_error_solutions', nor does it specify context or prerequisites for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze tool usage patterns, workflows, and successful practices
| Name | Required | Description | Default |
|---|---|---|---|
| tool_name | No | Optional specific tool name to analyze | |
| pattern_type | No | Type of patterns: tools, workflows, or solutions | tools |
| limit | No | Maximum number of patterns (default: 12) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions analysis but does not detail how the analysis is performed, what data sources are used, whether it involves read-only operations or mutations, or any rate limits or permissions required. This leaves significant gaps in understanding the tool's behavior beyond its basic purpose.
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 without unnecessary details. It avoids redundancy and waste, making it easy to parse. However, it could be slightly more structured by explicitly separating the analysis focus from the output implications, but overall it is appropriately concise for the tool's complexity.
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 (analysis of patterns with 3 parameters) and lack of annotations or output schema, the description is incomplete. It does not explain what the analysis yields, how results are formatted, or any behavioral traits like data sources or limitations. This makes it inadequate for an agent to fully understand the tool's operation and expected outcomes.
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 input schema has 100% description coverage, clearly documenting all three parameters with enums and defaults. The description adds no additional meaning beyond the schema, such as explaining how parameters interact or providing examples. Since schema coverage is high, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without extra description input.
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 states the tool 'analyze tool usage patterns, workflows, and successful practices,' which provides a general purpose but lacks specificity about what resources or data it operates on. It distinguishes itself from siblings like 'search_conversations' or 'list_recent_sessions' by focusing on patterns rather than direct data retrieval, but the verb 'analyze' is vague without clarifying the analysis method or output format.
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?
No explicit guidance is provided on when to use this tool versus alternatives. The description implies usage for analyzing patterns, but it does not specify scenarios, prerequisites, or exclusions. For example, it does not differentiate from 'find_similar_queries' or 'get_error_solutions,' leaving the agent to infer based on general terms without clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find solutions for specific errors with enhanced matching
| Name | Required | Description | Default |
|---|---|---|---|
| error_pattern | Yes | Error message or pattern to search for solutions | |
| limit | No | Maximum number of results (default: 8) | |
| detail_level | No | Response detail: summary (default), detailed, raw | summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'enhanced matching,' which hints at improved search capabilities, but doesn't explain what 'enhanced' entails, such as fuzzy matching or prioritization. It also omits details like rate limits, authentication needs, or response format, leaving gaps in understanding the tool's behavior.
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: 'Find solutions for specific errors with enhanced matching.' It's front-loaded with the core purpose and avoids unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, making it highly concise and well-structured.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose but lacks details on behavioral traits, usage context, or output expectations. While it covers the basics, it doesn't fully compensate for the absence of annotations or output schema, leaving room for improvement in completeness.
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 input schema has 100% description coverage, clearly documenting all parameters: 'error_pattern,' 'limit,' and 'detail_level.' The description doesn't add any extra semantic meaning beyond this, such as examples or usage tips. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate or enhance the parameter understanding.
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: 'Find solutions for specific errors with enhanced matching.' It specifies the verb ('Find') and resource ('solutions for specific errors'), making the function understandable. However, it doesn't explicitly differentiate from sibling tools like 'find_similar_queries' or 'search_conversations,' which might also involve error-related searches, so it doesn't reach the highest score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where this tool is preferred, such as for error troubleshooting versus general search. Without such distinctions, users might struggle to choose between this and tools like 'search_conversations' or 'find_similar_queries.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse recent sessions with smart activity detection and summaries
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of sessions (default: 10) | |
| project | No | Optional project name to filter sessions | |
| include_summary | No | Include intelligent session summaries (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'smart activity detection and summaries' which hints at some processing behavior, but doesn't disclose critical details like whether this is a read-only operation, what permissions might be needed, rate limits, or how the 'smart' detection works. The description is vague about actual behavioral traits.
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 gets straight to the point. Every word contributes to understanding the tool's purpose without any wasted text. It's appropriately sized and front-loaded with the core functionality.
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?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'recent' means temporally, what format the results come in, what 'smart activity detection' entails, or how summaries are generated. The description leaves too many questions unanswered for a tool that presumably returns structured session data.
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%, so the schema already fully documents all three parameters. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain how parameters interact or provide usage examples. Baseline 3 is appropriate when schema does 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 ('Browse') and resource ('recent sessions'), and mentions additional features ('smart activity detection and summaries'). However, it doesn't explicitly differentiate this tool from sibling tools like 'search_conversations' or 'extract_compact_summary', which might have overlapping functionality.
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 no guidance on when to use this tool versus alternatives. With siblings like 'search_conversations' and 'extract_compact_summary' available, there's no indication of when this browsing tool is preferred over those search or extraction tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search through Claude Code conversation history with smart insights
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find relevant conversations | |
| project | No | Optional project name to filter results | |
| timeframe | No | Time range filter (today, week, month) | |
| limit | No | Maximum number of results (default: 10) | |
| detail_level | No | Response detail: summary (default), detailed, raw | summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only vaguely mentions 'smart insights' without explaining what these entail (e.g., ranking, relevance scoring, or AI-enhanced filtering). It doesn't disclose behavioral traits like pagination, rate limits, authentication needs, or what 'search' means operationally (e.g., full-text, metadata). This leaves significant gaps for a search 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 a single, efficient sentence that front-loads the core purpose. However, 'smart insights' is vague and could be more precise. It avoids redundancy but misses opportunities to add critical context, making it slightly under-specified rather than optimally concise.
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?
For a search tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, error handling, or the 'smart insights' feature, leaving the agent unsure of behavioral outcomes. Given the complexity and lack of structured data, more detail is needed to guide effective tool 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%, so the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond what's in the schema, not explaining how 'query' interacts with 'smart insights' or clarifying parameter interdependencies. Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate with additional context.
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 searches through 'Claude Code conversation history with smart insights', specifying both the verb (search) and resource (conversation history). It distinguishes from siblings like 'list_recent_sessions' (which lists rather than searches) and 'find_similar_queries' (which focuses on queries rather than conversations). However, it doesn't explicitly mention what 'smart insights' entail, leaving some ambiguity.
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 no guidance on when to use this tool versus alternatives like 'list_recent_sessions' for recent conversations without search, 'find_similar_queries' for query analysis, or 'search_plans' for different content. It mentions 'smart insights' but doesn't clarify what contexts benefit from them versus basic search, offering no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Claude Code plan files for past implementation approaches, decisions, and patterns
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for plan content | |
| limit | No | Maximum number of results (default: 10) | |
| detail_level | No | Response detail level | summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches for 'past implementation approaches, decisions, and patterns,' implying a read-only operation, but doesn't cover critical aspects like authentication needs, rate limits, error handling, or response format. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 without unnecessary words. Every part of the sentence ('Search Claude Code plan files for past implementation approaches, decisions, and patterns') contributes directly to understanding the tool's function, making it appropriately concise and well-structured.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose but lacks usage guidelines, behavioral details, and output information. Without annotations or an output schema, the agent has incomplete context for effective tool invocation, though the schema provides good parameter coverage.
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%, so the schema fully documents all three parameters (query, limit, detail_level) with descriptions, defaults, and an enum. The description adds no additional parameter semantics beyond what's in the schema, such as query syntax examples or detail-level implications. This meets the baseline score of 3 when schema coverage is high.
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: 'Search Claude Code plan files for past implementation approaches, decisions, and patterns.' It specifies the verb ('Search'), resource ('Claude Code plan files'), and target content ('implementation approaches, decisions, and patterns'). However, it doesn't explicitly differentiate from sibling tools like 'search_conversations' or 'find_tool_patterns,' which might have overlapping search domains.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_conversations' or 'find_tool_patterns,' nor does it specify contexts, prerequisites, or exclusions for usage. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0extract_compact_summary2 fields changedInput schema / properties / focusAdded value: +{
+ "default": "all",
+ "description": "Focus area: solutions, tools, files, or all",
+ "enum": [
+ "solutions",
+ "tools",
+ "files",
+ "all"
+ ],
+ "type": "string"
+}Input schema / properties / max_messages / descriptionPrevious value: -"Maximum messages to include in summary (default: 10)"New value: +"Maximum messages to analyze (default: 10)"find_file_context4 fields changedInput schema / properties / detail_levelAdded value: +{
+ "default": "summary",
+ "description": "Response detail: summary (default), detailed, raw",
+ "enum": [
+ "summary",
+ "detailed",
+ "raw"
+ ],
+ "type": "string"
+}Input schema / properties / limit / defaultPrevious value: -20New value: +15Input schema / properties / limit / descriptionPrevious value: -"Maximum number of results (default: 20)"New value: +"Maximum number of results (default: 15)"Input schema / properties / operation_typeAdded value: +{
+ "default": "all",
+ "description": "Filter by operation: read, edit, create, or all",
+ "enum": [
+ "read",
+ "edit",
+ "create",
+ "all"
+ ],
+ "type": "string"
+}find_similar_queries3 fields changedInput schema / properties / detail_levelAdded value: +{
+ "default": "summary",
+ "description": "Response detail: summary (default), detailed, raw",
+ "enum": [
+ "summary",
+ "detailed",
+ "raw"
+ ],
+ "type": "string"
+}Input schema / properties / limit / defaultPrevious value: -10New value: +8Input schema / properties / limit / descriptionPrevious value: -"Maximum number of results (default: 10)"New value: +"Maximum number of results (default: 8)"find_tool_patterns3 fields changedInput schema / properties / limit / defaultPrevious value: -20New value: +12Input schema / properties / limit / descriptionPrevious value: -"Maximum number of patterns (default: 20)"New value: +"Maximum number of patterns (default: 12)"Input schema / properties / pattern_typeAdded value: +{
+ "default": "tools",
+ "description": "Type of patterns: tools, workflows, or solutions",
+ "enum": [
+ "tools",
+ "workflows",
+ "solutions"
+ ],
+ "type": "string"
+}get_error_solutions3 fields changedInput schema / properties / detail_levelAdded value: +{
+ "default": "summary",
+ "description": "Response detail: summary (default), detailed, raw",
+ "enum": [
+ "summary",
+ "detailed",
+ "raw"
+ ],
+ "type": "string"
+}Input schema / properties / limit / defaultPrevious value: -10New value: +8Input schema / properties / limit / descriptionPrevious value: -"Maximum number of results (default: 10)"New value: +"Maximum number of results (default: 8)"list_recent_sessions2 fields changedInput schema / properties / include_summaryAdded value: +{
+ "default": true,
+ "description": "Include intelligent session summaries (default: true)",
+ "type": "boolean"
+}Input schema / properties / projectAdded value: +{
+ "description": "Optional project name to filter sessions",
+ "type": "string"
+}search_conversations3 fields changedInput schema / properties / detail_levelAdded value: +{
+ "default": "summary",
+ "description": "Response detail: summary (default), detailed, raw",
+ "enum": [
+ "summary",
+ "detailed",
+ "raw"
+ ],
+ "type": "string"
+}Input schema / properties / limit / defaultPrevious value: -50New value: +10Input schema / properties / limit / descriptionPrevious value: -"Maximum number of results (default: 50)"New value: +"Maximum number of results (default: 10)"search_plansextract_compact_summaryfind_file_contextfind_similar_queriesfind_tool_patternsget_error_solutionslist_recent_sessionssearch_conversationsMost tools have clearly distinct purposes, such as extract_compact_summary for session summaries and find_file_context for file-related conversations. However, find_similar_queries and search_conversations could potentially overlap in functionality, as both involve searching through conversation history, which might cause minor confusion for an agent.
All tool names follow a consistent verb_noun pattern with snake_case, such as extract_compact_summary, find_file_context, and search_conversations. This predictability makes it easy for an agent to understand and navigate the tool set without naming-related confusion.
With 8 tools, the server is well-scoped for its purpose of analyzing conversation history and patterns. Each tool appears to serve a specific function, such as summarizing sessions, finding errors, or searching plans, making the count appropriate and manageable for the domain.
The tool set covers key aspects of conversation analysis, including summarization, searching, error resolution, and pattern detection. A minor gap might be the lack of tools for modifying or annotating historical data, but the surface is largely complete for querying and insights, allowing agents to work effectively within the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
An MCP server that gives your AI access to the source code and docs of all public github repos
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Vvkmnn/claude-historian-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
