마크다운 파일에 대한 시맨틱 검색입니다. 키워드뿐만 아니라 의미를 기반으로 관련 노트를 찾습니다. 새 노트를 만들기 전에 중복을 감지합니다.
두 가지 서버 전송 방식을 지원합니다:
stdio MCP — Claude Code 통합용 (세션당 하나의 프로세스)
HTTP — 하나의 포트에서 MCP-over-HTTP와 REST를 결합; 모든 클라이언트가 공유하는 하나의 웜 프로세스
sentence-transformers를 사용한 시맨틱 검색
중복/유사 노트 감지
파일 감시자를 통한 자동 인덱스 업데이트
다중 디렉토리 지원
인라인 태그 추출 (#tag-name)
Related MCP server: mcp-recall-md
CPU 전용 설치 — macOS(모든 Mac, Apple Silicon 또는 Intel) 및 NVIDIA GPU가 없는 Linux/Windows에 권장됩니다. 약 5GB의 CUDA 바이너리를 절약합니다. macOS에서는 Apple GPU(MPS)가 PyTorch의 내장 MPS 백엔드를 통해 자동으로 감지되어 사용됩니다. "CPU" 라벨은 CUDA가 없음을 의미할 뿐, 런타임 시 컴퓨팅 장치를 의미하지는 않습니다.
uv tool install --index https://download.pytorch.org/whl/cpu \
git+https://github.com/bborbe/semantic-searchCUDA 설치 — 전용 NVIDIA GPU가 있는 Linux/Windows 전용입니다. macOS에는 적용되지 않습니다 (Mac에서는 NVIDIA CUDA가 지원되지 않음).
uv tool install git+https://github.com/bborbe/semantic-searchuv tool upgrade semantic-searchClaude Code 세션당 하나의 프로세스를 생성합니다. 간단하지만 각 세션이 약 400MB~1GB의 모델 사본을 로드합니다.
claude mcp add -s project semantic-search \
--env CONTENT_PATH=/path/to/vault \
-- \
uvx --from git+https://github.com/bborbe/semantic-search semantic-search-mcp사용 가능한 도구:
search_related(query, top_k=5) — 의미적으로 관련된 노트 찾기
check_duplicates(file_path) — 중복/유사 노트 감지
단일 장기 실행 프로세스가 /mcp에서 MCP-over-HTTP를, /search, /duplicates, /health, /reindex에서 REST를 제공합니다. 모든 Claude Code 세션과 REST 클라이언트가 하나의 웜 인덱서를 공유합니다.
CONTENT_PATH=/path/to/vault semantic-search-http --host 127.0.0.1 --port 8321MCP 설정을 통해 Claude Code를 가리킵니다:
{
"mcpServers": {
"semantic-search": {
"type": "http",
"url": "http://127.0.0.1:8321/mcp"
}
}
}REST 엔드포인트:
엔드포인트 | 메서드 | 설명 |
| POST | MCP-over-HTTP (Claude Code) |
| GET | 시맨틱 검색 |
| GET | 중복 노트 찾기 |
| GET | 인덱스 상태를 포함한 상태 확인 |
| GET/POST | 인덱스 강제 재구축 |
예시 쿼리:
# Search
curl 'http://127.0.0.1:8321/search?q=kubernetes+deployment'
# Find duplicates
curl 'http://127.0.0.1:8321/duplicates?file=notes/my-note.md'
# Health check
curl 'http://127.0.0.1:8321/health'이 저장소는 설정, 검색 및 조사를 위한 명령어가 포함된 Claude Code 마켓플레이스 플러그인으로도 제공됩니다.
claude plugin marketplace add bborbe/semantic-search
claude plugin install semantic-searchclaude plugin marketplace update semantic-search
claude plugin update semantic-search@semantic-search# One-shot interactive setup: installs the binary, writes the launchd/systemd
# unit, registers the MCP server in your Claude config.
/semantic-search:configure
# Search indexed markdown
/semantic-search:search kubernetes deployment
# Multi-step research across results
/semantic-search:research kafka backup strategy명령어 | 설명 |
|
|
| 실행 중인 MCP 서버를 통한 시맨틱 검색 |
| 다단계 조사 — 검색, 분류, 상위 소스 읽기, 종합 |
프로덕션 스타일의 사용을 위해 semantic-search-http를 백그라운드 서비스로 실행하여 모든 Claude Code 세션(및 모든 REST 클라이언트)이 하나의 웜 프로세스를 공유하도록 합니다.
플랫폼 | 가이드 |
macOS (launchd) | |
Linux (systemd) |
빠른 예시 (macOS):
launchctl load ~/Library/LaunchAgents/com.github.bborbe.semantic-search-http.plist빠른 예시 (Linux):
systemctl --user enable --now semantic-search-http.service서버를 실행하지 않는 일회성 명령어:
# Search
CONTENT_PATH=/path/to/vault semantic-search search "kubernetes deployment"
# Find duplicates
CONTENT_PATH=/path/to/vault semantic-search duplicates path/to/note.md바이너리 | 목적 |
| 결합된 HTTP 서버 — |
| stdio MCP 서버 — Claude Code 세션당 하나. HTTP 서비스가 설정되지 않았을 때 사용. |
| CLI 전용 — |
변수 | 설명 | 기본값 |
| 인덱싱할 디렉토리 (여러 개일 경우 쉼표로 구분) |
|
| 로깅 레벨 (DEBUG, INFO, WARNING, ERROR) |
|
경로를 쉼표로 구분하여 여러 디렉토리를 인덱싱합니다:
CONTENT_PATH=/path/to/vault1,/path/to/vault2,/path/to/docs모든 디렉토리는 함께 인덱싱되며 하나의 통합 인덱스로 검색됩니다.
첫 실행 시 작은 임베딩 모델(~90MB)을 다운로드하고 마크다운 파일을 인덱싱합니다(일반적인 볼트의 경우 1초 미만). 파일 시스템 감시자를 통해 파일이 변경되면 인덱스가 자동으로 업데이트됩니다.
각 마크다운 파일은 가중치가 적용된 구성 요소로 인덱싱됩니다:
구성 요소 | 가중치 | 참고 |
파일명 | 3x | |
Frontmatter | 3x | |
Frontmatter | 2x | 인라인 태그와 병합 |
Frontmatter | 2x | |
인라인 태그 ( | 2x | 본문에서 추출 |
첫 번째 H1 제목 | 2x | |
본문 콘텐츠 | 1x | 처음 500단어 |
# Clone
git clone https://github.com/bborbe/semantic-search
cd semantic-search
# Install dev dependencies
make install
# Run checks
make check
# Run tests
make testBSD 2-Clause 라이선스 — LICENSE를 참조하세요.
Find notes that are potential duplicates of the given file.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the file (absolute or relative to content directory) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral details beyond the basic 'Find' action—such as how duplicates are determined, whether the operation is read-only, or any side effects. The burden falls on the description, which is minimal.
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, front-loaded sentence with no wasted words, making it highly concise and easy to parse.
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 simplicity (one parameter, output schema present), the description conveys the main purpose adequately. However, it lacks guidance on when to use vs alternatives, which is somewhat a gap but not critical for such a straightforward tool.
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% for the single parameter, so the schema fully describes file_path. The description adds no extra semantic meaning beyond what the schema already states.
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 uses a specific verb ('Find') and resource ('notes that are potential duplicates of the given file'), clearly distinguishing it from sibling tools like search_related and get_content.
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 for checking duplicates but does not explicitly state when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the content of a file from the indexed vault.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path (absolute or relative to an indexed root) | |
| query | No | Search string to find the best-matching line (only used when snippet=True) | |
| snippet | No | If True, return a snippet around the best-matching line instead of the full file | |
| context_lines | No | Number of lines before and after the match to include (default 20) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 only states the primary action but does not disclose edge cases (e.g., file not found, path resolution), or behavior around optional parameters like snippet and query despite their existence in the schema. This leaves significant behavioral aspects undisclosed.
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, tightly worded sentence that immediately conveys the core purpose. There is no fluff or redundancy, and the information is front-loaded. For the tool's purpose, this length is appropriately 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?
The tool has moderate complexity with optional snippet/query parameters and an output schema, and the schema covers parameter semantics. However, the description is thin on operational context, such as how path resolution works or when to use snippet mode. While not incomplete for basic selection, the description itself needed to provide more contextual glue; the schema partially compensates, but gaps remain.
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 a baseline of 3 is appropriate. The description itself does not add any parameter semantics beyond the schema, but the schema already documents each parameter (path, query, snippet, context_lines) clearly. The description neither enhances nor detracts from what the schema provides.
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 action ('Fetch the content of a file') and the resource ('indexed vault'), using a specific verb and resource. It distinguishes itself from sibling tools 'search_related' and 'check_duplicates' by focusing on direct content retrieval rather than search or duplication checks.
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 does not mention related tools or any exclusionary conditions (e.g., 'use search_related instead when looking for related content'). The intended usage is only implicitly derived from the tool's name and action.
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.
v0.1.0check_duplicatesget_contentsearch_relatedScored across 3 tools
Each tool serves a distinct purpose: semantic search, duplicate detection, and content retrieval. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern (search_related, check_duplicates, get_content) using snake_case. The naming is predictable and readable.
Three tools is an appropriate, focused set for a semantic search server. Each tool earns its place and the scope is well-defined.
The server covers the core needs of semantic search: finding related notes, detecting duplicates, and retrieving content. There are no missing operations that would hinder its stated purpose.
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Personal context for every AI: search, read, and write back to your private Markdown library.
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…
Markdown notes in folders, with files, that your AI assistant can read, write and organise.
