Skip to main content
Glama

claude-find

필요할 때 언제든지 Claude Code 세션 전체에서 Deep Memory를 불러오세요.

demo

과거의 모든 Claude Code 세션에 대해 의미론적 검색을 수행합니다. 의미와 키워드를 통해 컨텍스트를 찾습니다. 압축된 요약이 아닌 원본 대화 기록을 검색하므로 Claude는 추론, 제약 조건, 실패한 접근 방식, 결정 사항 등 전체적인 상황을 파악할 수 있습니다.

설정

brew install bun ollama
bunx claude-find setup

setup은 Ollama를 시작하고, 임베딩 모델을 가져오며, 세션 보존 기간을 영구로 설정하고, Claude Code에 MCP 서버를 등록합니다. 세션은 시작 시 백그라운드에서 인덱싱됩니다. 검색은 즉시 작동하며 인덱싱이 계속됨에 따라 점진적으로 더 완전한 결과를 반환합니다.

Bun과 Ollama를 설치한 다음 bunx claude-find setup을 실행하세요. 플랫폼을 감지하고 누락된 항목이 있으면 안내해 드립니다.

Related MCP server: am-memory

사용 방법

Claude Code 세션 내에서:

/find that database migration we discussed last week
/find why we chose websockets over polling
/find the session where we kept getting timeout errors
/find refactoring the payment module across all projects

Claude가 과거 세션을 의미론적으로 검색하여 관련 대화를 찾고, 시도했던 내용, 실패한 내용, 설정한 제약 조건, 결정된 사항 등의 컨텍스트를 종합합니다.

작동 원리

  1. 인덱싱: ~/.claude/projects/에 있는 모든 Claude Code 세션 JSONL 파일을 인덱싱합니다.

  2. 추출: 사용자 및 어시스턴트 메시지, 간략한 요약, 도구 호출의 파일 경로를 추출합니다.

  3. 강화: 더 나은 검색을 위해 각 청크에 메타데이터 컨텍스트(프로젝트, 브랜치, 파일, 날짜)를 추가합니다.

  4. 임베딩: Ollama를 통해 qwen3-embedding을 사용하여 대화 청크를 임베딩합니다(GPU 가속).

  5. 검색: Reciprocal Rank Fusion을 통해 병합된 하이브리드 의미론적 + 키워드(FTS5) 검색을 수행합니다.

  6. 반환: Claude가 전체 컨텍스트를 종합할 수 있도록 원본 대화 청크를 반환합니다.

업그레이드 후에는 bunx claude-find index를 실행하여 최신 개선 사항이 반영된 인덱스를 다시 빌드하세요.

차별점

  • 원본 기록 검색: 압축으로 인해 손실되는 정보가 없습니다.

  • 소급 적용: 기존의 모든 세션에서 즉시 작동합니다. 별도의 후크가 필요하지 않습니다.

  • 영구 기록: 설정 시 Claude Code의 30일 세션 정리 기능을 비활성화하여 세션을 영구적으로 검색할 수 있습니다.

  • 비차단 방식: 시작 시 백그라운드에서 인덱싱합니다. 인덱싱 중에도 검색은 즉시 작동합니다.

  • 간략한 요약 활용: Claude가 자체적으로 이해한 세션 내용을 순위 결정에 활용합니다.

  • 도구 호출 메타데이터 인덱싱: 수정된 파일, 발생한 오류 등을 기준으로 검색합니다.

  • 빠른 속도: Ollama + GPU를 사용하여 인덱싱 속도를 유지하고 메모리 사용량을 제한합니다.

요구 사항

  • Bun 런타임

  • Ollama (최초 사용 시 모델 자동 다운로드)

  • Claude Code

라이선스

MIT

Available Tools

1 tool
search_sessionsA

Search the full conversation history from past Claude Code sessions stored in ~/.claude/projects/. This tool has access to the complete raw transcripts of all previous sessions — including the actual back-and-forth discussion, reasoning, failed approaches, user constraints, and code decisions. Use this tool FIRST whenever the user mentions anything from a past session, asks 'what did we discuss', 'pull in context from', 'remember when we', 'how did we handle', or references any prior work. This tool searches semantically — the user doesn't need to remember exact words. Much more detailed than built-in memory.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesWhat to search for — natural language description of the past session or topic
max_sessionsNoMax sessions to return (default 3, max 5)
max_chunksNoMax conversation chunks per session (default 3, max 3)
scopeNo'current' searches only the current project (default), 'all' searches across all projects. Use 'all' when user says 'across all projects' or doesn't specify a project.current
project_filterNoFilter to a specific project by name (e.g. 'visk', 'myapp'). Use when user says 'in visk' or 'in the payments project'.

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses the scope of data ('complete raw transcripts', 'discussion, reasoning, failed approaches') and the semantic search nature. It does not mention any destructive actions or potential privacy concerns, but for a read-only search tool, the disclosure is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with four sentences, starting with the core purpose and then usage guidance. Every sentence contributes meaning, though it could be slightly trimmed without loss.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately explains the tool's function and when to use it, but it does not describe the return value format or content. The schema hints at output via parameters like max_sessions and max_chunks, but without an output schema, the description should explicitly state what is returned (e.g., matching sessions with chunks).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed parameter descriptions. The tool description adds context about the underlying data ('complete raw transcripts') that enriches understanding of what the 'query' parameter searches over, going beyond the schema's literal description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches 'full conversation history from past Claude Code sessions' and specifies the exact storage location. It distinguishes itself from built-in memory by claiming to be 'much more detailed', which is useful even though no siblings are listed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use the tool first, listing example phrases like 'what did we discuss' and 'remember when we'. It also explains that searches are semantic, reducing the need for exact words, which is a clear usage recommendation.

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.

  1. 1 tool update
    • First observedsearch_sessions

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion between tools. The tool's purpose is clearly defined.

Naming Consistency5/5

The single tool name 'search_sessions' follows a consistent verb_noun pattern, though there are no other tools to compare against.

Tool Count3/5

A single tool for searching is borderline thin; most servers of this scope would benefit from at least 2-3 tools (e.g., list_sessions, get_session). The count is at the low end of reasonable.

Completeness4/5

The tool covers the core search functionality well, but lacks complementary tools such as listing available sessions or retrieving full transcripts by ID, which would make the surface more complete.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    C
    maintenance
    Enables AI assistants to query and analyze past Claude Code sessions, providing structured insights like file changes, decisions, errors, and git history across projects.
    11
    9 npm
    1
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Persistent memory for Claude Code — a self-evolving knowledge layer that survives across sessions, grows from every conversation, and surfaces relevant context automatically.
    14
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables Claude Code to search and retrieve past chat history from Claude.ai exports and Claude Code sessions, allowing the AI to reference previous conversations and decisions.
    MIT