Conversation history search across Claude Code sessions. Searches through Claude Code conversation history, .claude files (rules, skills, agents, plans, CLAUDE.md), memories, and task management data with smart insights.
The server exhibits severe structural problems that make it unsuitable for production use. The primary issue is tool definition inconsistency: 10 of 12 tools (83%) are documented as 'Tool renamed' stubs with empty input schemas in dxt/server.js, while only 2 tools ('search' and 'inspect') have properly defined schemas in src/index.ts. This split definition creates confusion, the actual tool surface is unclear. Of the 2 implemented tools, 'search' has a comprehensive schema but only moderate parameter descriptions, while 'inspect' is similarly under-described. The stub tools (search_conversations, find_file_context, find_similar_queries, get_error_solutions, search_plans, search_config, search_tasks, list_recent_sessions, find_tool_patterns, extract_compact_summary) carry descriptions like 'Tool renamed → search(scope: "conversations")' which are metadata comments, not user-facing descriptions. None of these stubs have visible input schemas, they are inferred as aliases but not properly registered. This violates the rule: 'If you cannot see the actual tool definition in the source, cap that tool's overall at 50.' Additionally, error handling is minimal (only 'errorReporting' noted as true, but no error classification, recovery guidance, or actionable error messages visible in code). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present in the visible schema definitions. The server reads local conversation history, a benign operation, but lacks security controls such as audit logging, rate limiting, or scope declarations.
10 of 12 tools have descriptions that are metadata comments ('Tool renamed → ...') rather than user-facing descriptions. Without one, LLMs cannot determine when or why to select the tool.'
Consolidate tool definitions into a single, canonical list. Choose either dxt/server.js or src/index.ts as the source of truth. Do not split tool registration across files, this creates confusion and maintenance debt.
Convert alias/stub tools into proper tool registrations. Either fully define search_conversations, find_file_context, etc. with their own schemas and descriptions, OR remove them and expose only 'search' with a scope parameter. Avoid metadata comments like 'Tool renamed → ...' as user descriptions.
Write proper tool descriptions for all 12 tools. Each should be 50 - 200 characters and answer: WHAT does it do? WHEN should the LLM call it instead of a similar tool? Examples:
- search: 'Search conversation history and .claude files by query or scope (conversations, files, errors, tasks, etc.). Use to retrieve prior context or find related discussions.'
- inspect: 'Summarize a single conversation session with key insights, solutions, files touched, or tools used. Use after search() to dive deep into one session.'
Add detailed parameter descriptions. For every parameter, specify:
- Expected format (e.g., ISO 8601 date, comma-separated values, regex pattern)
- Constraints (min/max for numbers, length limits for strings, valid enum values)
- Examples only in the schema (not description text) to avoid LLM hallucination
Example: 'timeframe' → 'Time range filter: one of today, week, month, or a custom ISO 8601 range like 2024-01-15T00:00:00Z to 2024-01-31T23:59:59Z'
Document output schemas for 'search' and 'inspect'. Specify the fields, types, and pagination structure. Example:
search() returns: { results: [ { session_id, title, summary, relevance_score }, ... ], total_count, limit, offset }
Score history
Overall score trend
↑ 34 points across a rubric change (v1 → v2)
34/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
34
2026-07-28+
v2
2026-03-09
F
0
-
v1
source verified
77/100
Search through Claude Code conversation history, .claude files (rules, skills, agents, plans, CLAUDE.md), memories, and task management data with smart insights
Split tool definitions across dxt/server.js and src/index.ts create ambiguity about the canonical tool surface. The dxt/server.js file defines stub tools with empty schemas while src/index.ts likely contains the actual implementation, but it is not fully visible in the provided source. This violates composability and makes testing/integration unclear.
Parameter descriptions in 'search' and 'inspect' are terse and lack actionable detail. Example: 'timeframe' param in search has description 'Time range filter (today, week, month)' but no format specification or explanation of how the value is parsed.
No output schemas documented for any tool. LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.' The 'search' tool returns results, but the structure (fields, types, pagination) is not documented.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present in any tool schema. The MCP spec 2026-07-28 supports tool annotations to help agents reason about side effects. This server reads conversation history (read-only) but does not declare this intent.
No error handling guidance visible. Tools may fail (e.g., if a session is not found, or the search index is unavailable) but no recovery hints, error classification, or actionable messages are visible in the code. Try search_users() with a partial name."'
No security controls visible (audit logging, rate limiting, scope declarations, permission checks). The server reads local conversation history, which is lower-risk than network APIs, but should still log access and limit caller permissions.
Add tool annotations to all tools:
- readOnlyHint: true for search, inspect, and all scope variants (no side effects)
- This informs agents that these calls are safe to retry and do not modify state
Implement error handling with recovery guidance. Map failure modes to next steps:
- Session not found → 'Could not find session ABC123. Call list_recent_sessions() to see available sessions.'
- Search returned no results → 'No conversations matched "query text". Try broadening the query or changing scope.'
- Timeout → 'Search timed out. Try a narrower query, shorter timeframe, or smaller limit.'
Per pattern: recovery-guide (https://arcade.dev/patterns/recovery-guide)
Add per-tool permission hints in descriptions. Example:
- search, inspect: 'Requires read:history permission. Does not modify any data.'
This helps agents understand their privilege level and informs audit trails.
Validate all inputs early and return clear error messages:
- If scope is invalid → 'Invalid scope: got "invalid_scope". Must be one of: all, conversations, files, errors, plans, config, tasks, similar, sessions, tools, memories'
- If limit > 1000 → 'Limit too high: 1500 > 1000. Max is 1000.'
Per pattern: constrained-input (https://arcade.dev/patterns/constrained-input)
Add batch/pagination support to search if not already present. If results can exceed 50 items, support limit and offset parameters and return a total_count. Without pagination, large result sets exhaust the context window.
Remove or deduplicate tool aliases. If search_conversations is just search with scope='conversations', remove the alias and rely on the scope enum. One canonical tool per intent reduces agent confusion and maintenance overhead. Per pattern: tool-composition.