Markdownファイルに対するセマンティック検索。キーワードだけでなく、意味で関連するノートを見つけます。新しいノートを作成する前に重複を検出します。
2つのサーバー転送方式をサポートしています：
stdio MCP — Claude Code統合用（セッションごとに1プロセス）
HTTP — 1つのポートでMCP-over-HTTPとRESTを統合。すべてのクライアントで共有される1つのウォームプロセス
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セッションごとに1つのプロセスを生成します。シンプルですが、各セッションが約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クライアントが1つのウォームインデクサーを共有します。
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クライアント）が1つのウォームプロセスを共有できるようにします。
プラットフォーム | ガイド |
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セッションごとに1つ。HTTPサービスが設定されていない場合に使用。 |
| CLI専用 — |
変数 | 説明 | デフォルト |
| インデックス対象ディレクトリ（複数指定はカンマ区切り） |
|
| ログレベル (DEBUG, INFO, WARNING, ERROR) |
|
パスをカンマで区切ることで、複数のディレクトリをインデックス化できます：
CONTENT_PATH=/path/to/vault1,/path/to/vault2,/path/to/docsすべてのディレクトリは一緒にインデックス化され、1つの統合インデックスとして検索されます。
初回実行時に小さな埋め込みモデル（約90MB）をダウンロードし、Markdownファイルをインデックス化します（一般的なボルトであれば1秒未満）。ファイルシステム監視により、ファイル変更時にインデックスが自動更新されます。
各Markdownファイルは、重み付けされたコンポーネントでインデックス化されます：
コンポーネント | 重み | メモ |
ファイル名 | 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 — 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.
