Local Vector Search MCP

LocalVectorSearchMcp

Codex、Claude Code、ChatGPT に、ローカルで編集可能な、プロジェクトを認識する Markdown 作業環境を提供します。

LocalVectorSearchMcp は、1 つのプロジェクトの Markdown ファイルをプロジェクト内の SQLite データベースにインデックス化する、ローカル MCP サーバーです。エージェントは検索、焦点を絞ったセマンティックな範囲の読み取り、セマンティックポインターによる編集、Markdown ファイルの管理、ワークスペース内の移動、一般的な画像アセットの管理を行えます。

ドキュメント全体をコンテキストに読み込まずに、適切な仕様、アーキテクチャ上の決定、ガイド、または不変条件をエージェントが見つけられるよう支援します。

なぜ使うのか？

大規模なリポジトリには答えが含まれていることが多いものの、エージェントが最初に開いたファイルにあるとは限りません。

• 完全一致検索では、識別子、API 名、引用された用語を見つけられます。
• ベクトル検索では、表現が異なっていても、概念的に関連するドキュメントを見つけられます。
• ハイブリッド検索では、Reciprocal Rank Fusion によって両方の結果リストを組み合わせます。
• kb_read は、エージェントにファイル全体を読ませたり、インデックス作成の完了を待たせたりせず、現在の Markdown ソースから焦点を絞った範囲を返します。
• 要素単位の楽観的同時実行制御により、読み取り後に変更されたセマンティックな対象をエージェントが上書きするのを防ぎます。一方、ドキュメント内の無関係な編集はパッチを妨げません。
• ファイル監視を有効にすると、VS Code、Obsidian、その他のエディターによる編集にインデックスを同期できます。
• PNG、JPEG、WebP、GIF ファイルは、knowledgeBase.root（デフォルトは images/）内の任意の場所に、インデックス化されないアセットとして保存できます。
• プロジェクトごとに独自のローカル SQLite インデックスが作成されます。
• クラウドデータベースや必須の YAML 設定は不要です。

仕組み

Workspace Markdown (source of truth)
       ↓
Markdown elements and search chunks
       ↓
SQLite FTS5 (+ sqlite-vec when embeddings are enabled)
       ↓
Scoped retrieval + semantic editing
       ↓
MCP tools over stdio

images/ assets
       ↓
save / list / load / delete / safe move
       ↓
not indexed

Claude Code と Codex は stdio サーバーを直接起動できます。ChatGPT は OpenAI Secure MCP Tunnel を介して同じ MCP インターフェースを利用できます。この場合、外部の tunnel-client が ChatGPT とローカルの stdio プロセスを中継します。

クイックスタート：オフラインの字句検索

.NET ツールをインストールします（.NET 10 が必要です）。

dotnet tool install --global DimonSmart.LocalVectorSearchMcp

または、dnx で公開済みのバージョンを指定して直接実行できます（.NET 10 SDK が必要です。グローバルツールのインストールは不要です）。

dnx DimonSmart.LocalVectorSearchMcp@<version> --yes -- \
  --project-root "$PWD" --embedding-provider none --search-mode lexical --status

公式 MCP Registry では、正規名 io.github.DimonSmart/local-vector-search-mcp が使用されています。一致する NuGet リリースの登録が正常に完了した後にのみ、掲載されます。

グローバルインストールをせずに dnx でサーバーを登録するには、次のコマンドを実行します。

codex mcp add local-vector-search -- dnx DimonSmart.LocalVectorSearchMcp@<version> --yes -- \
  --project-root "$PWD" --embedding-provider none --search-mode lexical --watch-files

claude mcp add --transport stdio local-vector-search -- dnx DimonSmart.LocalVectorSearchMcp@<version> --yes -- \
  --project-root "$PWD" --embedding-provider none --search-mode lexical --watch-files

<version> を NuGet.org で公開されているバージョンに置き換え、Markdown プロジェクトのルートからコマンドを実行します。ここではサーバーは stdio とオフラインの字句検索モードを使用するため、Ollama エンドポイントや API キーは不要です。

インデックス化するプロジェクトから、次のコマンドを実行します。Ollama サーバー、リモートの埋め込みエンドポイント、API キーは不要です。

local-vector-search-mcp --project-root "$PWD" \
  --embedding-provider none --search-mode lexical --reindex

同じ引数を使用して、プロジェクト固有の MCP サーバーを登録します。

codex mcp add local-vector-search -- \
  local-vector-search-mcp --project-root "$PWD" \
  --embedding-provider none --search-mode lexical --watch-files

SQLite FTS5 インデックスは、プロジェクトルートの .local-vector-search-mcp/index.db に保存されます。Markdown が信頼できる唯一の情報源です。YAML で knowledgeBase.allowWrites: true を明示的に設定しない限り、サーバーは Markdown と画像に対して読み取り専用です。

.idd/intent、明示的なパス、dnx、Claude Code の使用方法については、IDD 統合例を参照してください。

オプション：ハイブリッド／セマンティック検索のクイックスタート

1. ツールと埋め込みモデルをインストールする

dotnet tool install --global DimonSmart.LocalVectorSearchMcp
ollama pull bge-m3:latest

初回の再インデックスを行う前に、Ollama が実行中であることを確認してください。

2. クライアントを接続する

ドキュメントをインデックス化するプロジェクトからコマンドを実行します。

Claude Code

claude mcp add local-vector-search \
  --scope local \
  --transport stdio \
  -- local-vector-search-mcp

Codex

codex mcp add local-vector-search \
  -- local-vector-search-mcp

ChatGPT

LocalVectorSearchMcp はローカルの stdio サーバーとして使用し、OpenAI Secure MCP Tunnel で中継します。トンネルを使用する場合は、ナレッジベースとストレージのパスを絶対パスで指定した設定を使用してください。

Secure MCP Tunnel 経由での ChatGPTを参照してください。

3. エージェントにインデックスの初期化と使用を依頼する

Check the local documentation index status. Reindex it if necessary,
then find the project's main architectural decisions and summarize them
with file references.

デフォルトでは、サーバーは検出されたプロジェクトルート以下の *.md ファイルをインデックス化し、インデックスを .local-vector-search-mcp/index.db に保存します。

セットアップと検証の手順については、はじめにを参照してください。

タスクの例

Before changing the indexing pipeline, find the documented architectural
decisions and constraints that apply to it.

Search the project documentation for rules governing persisted state.
Summarize the relevant invariants and cite the source files.

Attach this PNG and save it as cover.png in the project images folder.
Return the Markdown image reference.

機能

機能	実装
完全一致検索	SQLite FTS5 と BM25
セマンティック検索	sqlite-vec
ハイブリッドランキング	Reciprocal Rank Fusion
ストレージ	プロジェクトローカルの SQLite
インデックス対象コンテンツ	Markdown
編集可能なコンテンツ	Markdown。要素およびサブツリーのハッシュによる厳密な保護付き
画像アセット	PNG、JPEG、WebP、GIF。すべての画像ツールはルート相対パスを使用し、デフォルトでは images/ に保存します
ナビゲーション	ファイル一覧、画像一覧、見出しのアウトライン
トランスポート	stdio 経由の MCP
クライアント	Claude Code、Codex、OpenAI Secure MCP Tunnel 経由の ChatGPT
デフォルトの埋め込み	Ollama 互換のローカルエンドポイント。オフラインで FTS5 のみを使用する場合は embedding.provider: none を指定します

MCP サーバーは 18 個のツールを公開します。MCP による再インデックス化は非同期です。kb_reindex は単一のアクティブな再インデックス処理を開始または参加し、すぐに戻ります。一方、kb_status.indexing は進行状況と直近の結果を報告します。CLI の --reindex コマンドは引き続き同期処理で、インデックス化が完了した後にのみ終了します。

• kb_status — 現在のインデックスを確認します。
• kb_reindex — バックグラウンドでビルドまたは再ビルドを開始します。進行状況と最終結果は kb_status.indexing で確認します。
• kb_search — 導出されたインデックスに対し、必要に応じてパスを指定して、字句検索、セマンティック検索、またはハイブリッド検索を実行します。各結果には、インデックス化されたリビジョンを示す indexedSourceHash が含まれます。
• kb_read — セマンティックポインターから現在の Markdown ソースを読み取り、正確なソースリビジョン sourceHash を返します。
• kb_patch — 個々のセマンティック要素または見出しセクション全体をアトミックに置換・削除し、要素の前後に挿入します。
• kb_edit_table — ハッシュ付きテーブルポインターを介して、GFM テーブルのセル、行、列、配置をソースを考慮して編集します。
• kb_create、kb_move、kb_delete — Markdown ソースファイルを管理します。
• kb_list_files — Markdown ファイルとインデックス化されていないアセットを一覧表示します。ディレクトリまたは特定のファイルには pathPrefix を、ファイル名のパターンには includeGlob を使用します。
• kb_outline — 決定性のある見出しツリーを返します。
• kb_create_pdf_book — Markdown ドキュメントを整形済みの PDF ブックとしてレンダリングします。
• kb_download_file — 許可されたワークスペース内の任意のファイルを、ダウンロード可能なバイナリーリソースとして返します。
• kb_save_image — OpenAI のファイルパラメーターで渡された画像を保存します（targetPath は任意）。
• kb_list_images — サポート対象の画像アセットを再帰的に一覧表示し、カーソルでページネーションします。
• kb_load_image — 既存の画像を実際の MCP 画像コンテンツブロックとして返します。
• kb_delete_image — Markdown を変更せずに、ルート内のバイナリー画像を 1 つ削除します。
• kb_move_image — Markdown の参照を変更せずに、ルート内の任意の場所へバイナリー画像を安全に移動します。

低レベルの MCP 呼び出しやコネクター呼び出しでは、ユーザー引数を必要としないツールにも、明示的な空の arguments オブジェクトが必要です。標準の kb_status ワイヤー呼び出しは次のとおりです。

{
  "name": "kb_status",
  "arguments": {}
}

クライアントは引数オブジェクトを省略できることを前提にしないでください。引数を必要としないツールでは、{} が相互運用可能な仕様です。

ファイル一覧のフィルター

kb_list_files.pathPrefix は、ルート相対のディレクトリパスまたは特定のファイルパスです。部分的なファイル名のプレフィックスではありません。books と books/ は books/ 以下のファイルを含み、books/chapter.md はそのファイルのみを選択します。books/chapter は books/chapter.md に一致しません。ファイル名によるマッチングには includeGlob を使用します。両方のフィルターを指定した場合は、どちらも適用されます。

目的	引数
ディレクトリを一覧表示する	{ "request": { "pathPrefix": "books" } }
1 つのファイルを選択する	{ "request": { "pathPrefix": "books/chapter.md" } }
一致する名前を検索する	{ "request": { "includeGlob": "qa-*.md" } }
パターンの対象をディレクトリに限定する	{ "request": { "pathPrefix": "books", "includeGlob": "**/*.md" } }

PDF ブックのエクスポート

kb_create_pdf_book(path, outputPath?, pageFormat?, style?, profile?) は、ルート相対の Markdown ファイルから PDF を作成します。見出し、強調、コード、リスト、引用、リンク、GFM テーブル、ローカル画像をレンダリングします。デフォルトの出力先は、ソースと同じ名前に .pdf 拡張子を付けたパスです。knowledgeBase.root の配下に置く必要があります。閲覧用に派生したファイルとして、次回のエクスポート時に、そのパスにある既存の PDF はアトミックに置き換えられます。エクスポートには knowledgeBase.allowWrites: true が必要です。Markdown、アセット、検索インデックスは変更されず、{path,bytes,warnings} が返されます。利用できない画像は PDF 内でプレースホルダーとして表示され、warnings に含まれます。リモート画像 URL や絶対パスの画像 URL は取得されません。形式：a4、a5（デフォルト）、a6、b5、letter。スタイル：compact（デフォルト）、classic、modern、technical、academic。

プロファイル（アプリケーション定義のプリセット）：screen = 96 DPI／JPEG 品質 65、standard = 150 DPI／JPEG 品質 82（デフォルト）、print = 300 DPI／JPEG 品質 95。すべてのプロファイルで PDF の完全圧縮を使用し、Unicode テキストと画像のレイアウト／物理サイズを維持するとともに、埋め込み画像リソースを共有します。高解像度の JPEG と PNG はダウンサンプリングされる場合があります。変更のないファイルや、すでに効率的なファイルは元のエンコード形式のままです。EXIF／ICC／Adobe メタデータを含む JPEG と、明示的なカラー情報を含む PNG は、向きや色が変わるリスクを避けるため、そのまま保持されます。サポートされていない GIF／WebP は、レンダラーの従来の動作を維持します。出力サイズが kb_download_file の変更されていない 25 MiB の上限内に収まる保証はありません。Print は通常の印刷用であり、PDF/X、CMYK 出力、または印刷用の入稿前チェックを目的としていません。画像処理に以前より時間がかかる場合があります。デフォルトのプロファイルによって、以前にエクスポートした PDF のラスター画像の品質やサイズが変わる場合があります。

例（すべての呼び出しで既存のネストされた request を使用します）：

{"request":{"path":"book.md","outputPath":"exports/screen.pdf","profile":"screen"}}

{"request":{"path":"book.md","outputPath":"exports/standard.pdf"}}

{"request":{"path":"book.md","outputPath":"exports/print.pdf","pageFormat":"a4","style":"classic","profile":"print"}}

ワークスペースファイルのダウンロード

kb_download_file(path) は、ルート相対のワークスペースファイル 1 つの元のバイト列を、埋め込み MCP バイナリリソースとして返し、その後に {path,mimeType,bytes,sha256} メタデータを返します。書き込み権限がなくても使用でき、最大 25 MiB までの任意の通常ファイルに対応します。不明な拡張子には application/octet-stream が使用されます。絶対パス、パストラバーサル、.git、内部インデックスファイル、シンボリックリンク／ジャンクション／再解析ポイントを含むパスは拒否されます。画像プレビューや GIF から PNG への変換が必要な場合は、代わりに kb_load_image を使用してください。

画像アセット

5 つすべての画像ツールは、knowledgeBase.root の配下の任意の場所にある PNG、JPEG、WebP、GIF ファイルを扱えます。パスはルート相対です。.git/、内部 SQLite ファイル、パストラバーサル、シンボリックリンク／ジャンクション／再解析ポイントを含むパスは禁止されています。images/ は推奨されるデフォルトのフォルダーですが、API の制限ではありません。画像は通常のアセットであり、インデックス化も埋め込みもされません。

kb_save_image(file, fileName?, altText?, targetPath?) には allowWrites=true が必要で、OpenAI の openai/fileParams メタデータを保持します。クライアントで実際の画像をアップロードまたは選択し、生成されたファイル参照を渡してください。任意のテキスト、生の Base64、データ URI は有効な file の値ではありません。ツールを呼び出す前にクライアントがこれらを拒否した場合、サーバー側でそのクライアント側の検証を正規化することはできません。ダウンロードは引き続き HTTPS のみで、SSRF／リダイレクト対策、25 MiB のストリーミング上限、MIME／署名のチェック、SHA-256 による検証が適用されます。targetPath を指定しない場合、images/ に保存され、名前には fileName またはソースのベース名が使われます。同名ファイルがある場合は数値のサフィックスが付きます（cover.png、cover-2.png）。明示的な targetPath には最終的なファイル名と拡張子を含めます。安全な中間ディレクトリは作成できますが、使用中の保存先は絶対に名前を変更せず、上書きもしません（ALREADY_EXISTS）。targetPath と fileName の併用は無効です。

保存結果には path、mimeType、bytes、小文字表記の sha256、markdown が含まれます。生成される Markdown の保存先は、ワークスペースルートからの相対パスです。chapters/ 内のドキュメントで使用する場合、呼び出し元がそのドキュメントからの相対パスを再計算し、エスケープする必要があります。 kb_list_images(cursor?, pageSize?) は、ルート内のサポート対象画像拡張子を、大文字と小文字を区別せず、同じ場合は序数順で並べて一覧表示します。カーソルページネーションでは、既定で50項目（範囲：1～200）が返され、最後のカーソル項目が削除されている場合もサポートします。kb_load_image(path) は、シグネチャ、拡張子、サイズを検証します。MCP の結果には、最初に ImageContentBlock、次に元ファイルに関する JSON メタデータが含まれ、StructuredContent は含まれません。PNG／JPEG／WebP は元のバイト列を返します。GIF は、一部の ChatGPT コネクターで image/gif ブロックが公開されないため、最初のフレームを PNG 画像ブロック（image/png）としてレンダリングして返します。テキストメタデータには、元の GIF のパス、MIME タイプ、バイト数、SHA-256 が引き続き記録されます。元の GIF は変更されません。プレビューは静止画で、アニメーションは再生されません。

kb_move_image は、ルート内の任意の場所にある単一のバイナリ画像のみを名前変更または移動します。入力は {sourcePath,targetPath,expectedSha256?} です。expectedSha256 は省略可能な64桁の16進数の楽観的同時実行制御チェックです。不一致の場合は CONFLICT が返されます。Markdown のリンクは、別途 kb_read と kb_patch で更新する必要があります。応答は {previousPath,path,sha256} で、Markdown／インデックスのフィールドは含まれません。

kb_delete_image(path) は、Markdown からの参照をスキャンしたり、使用中かどうかを確認したり、親ディレクトリを削除したりせず、サポート対象のバイナリファイルを削除します。結果は引き続き {path,deleted:true} です。バイナリ画像の移動と削除は、どちらも Markdown のリンク切れを起こす可能性があります。画像操作によってインデックス作成がスケジュールされることはありません。

リンクを修復するには、適切にアドレス指定できる Markdown 要素に対して、別途 kb_read／kb_patch を呼び出してください。移動とパッチ適用のワークフローは、複数ファイルにまたがるトランザクションではありません。移動前に関連するドキュメントを見つけ、画像を移動し、現在のセマンティックアンカーを使って必要な要素にパッチを適用し、新しいパスを確認してください。安全にアドレス指定できない生のリンク構文は、任意のより大きなセクションを置き換えて書き換えてはなりません。復旧には Git を使用できます。

保存、移動、削除には次の権限が必要です。

knowledgeBase:
  allowWrites: true

予期されるツールエラーでは、IsError=true と、code および message を含む JSON テキストオブジェクト（例：INVALID_PATH、UNSUPPORTED_FORMAT、ALREADY_EXISTS、CONFLICT、PERMISSION_DENIED）が返されます。画像ツールには indexSynchronized がありません。Markdown の変更では、調整がすでに確認済みの場合、または調整が不要な場合に限り、その値は true になります。ソースの変更は成功したものの、調整がまだ確認されていない場合は false になります。

ローカル優先とプロジェクトの分離

各サーバープロセスは、1つのプロジェクトと、設定された1つの Markdown ルートに属します。MCP API を通じて、別のプロジェクトのインデックスを選択したり検索したりすることはできません。

既定の埋め込みエンドポイントはローカルの Ollama です。YAML で明示的に有効化されていない限り、リモート埋め込みエンドポイントは拒否されます。ドキュメントのテキスト、埋め込みテキスト、API キー、未加工のベクトル、署名付き画像ダウンロード URL はログに記録されません。

ドキュメント

• はじめに
• オフライン IDD 統合
• MCP Registry での検出（最初のレジストリリリース後にエントリーが利用可能になります）
• Claude Code のセットアップ
• Codex のセットアップ
• Secure MCP Tunnel 経由での ChatGPT
• 設定
• メンテナンスと更新
• 検証
• トラブルシューティング
• 製品仕様
• アーキテクチャ上の決定

編集可能なワークスペース

書き込みと外部ファイルの監視は、明示的に有効化する必要があります。

knowledgeBase:
  root: .
  allowWrites: true
  watchFiles: true

Markdown ファイルは、インデックス化されたナレッジの信頼できる情報源です。kb_read と kb_outline は現在のソースを直接解析します。kb_search は派生 SQLite インデックスを使用するため、一時的に古いインデックスのリビジョンを返す場合があります。Markdown の変更では、まずソースファイルをコミットし、その後、派生 SQLite インデックスの同期をスケジュールします。変更呼び出しは、調整の完了を待ちません。indexSynchronized: false は、ソースのコミットには成功したものの、派生インデックスとの同期がまだ確認されていないことを意味します。内部のセマンティックポインターは、引き続き論理的な構造アドレスです。公開される具体的な要素ポインターは logical~selfHash~subtreeHash 形式で、両方の値はソース全体の UTF-8 バイト列に対する16文字の小文字 XxHash64 ハッシュです。selfHash は要素自体を対象とします。見出しの subtreeHash は、replace_section と delete_section が所有するセクション全体のソース範囲を対象とし、リーフのハッシュは同一です。kb_patch は種類と selfHash のみで位置を再特定します。replace_section と delete_section は、さらに subtreeHash も検証します。kb_read は、kb_move や kb_delete などのファイル全体を対象とする操作のために、引き続き sourceHash を返します。

構造編集では、replace_element は Markdown 要素を1つだけ置き換え、delete は要素を1つだけ削除します。見出しを delete で削除しても、そのセクション本文は保持されます。replace_section は、見出しと、その見出しが所有するセクションのサブツリー全体を置き換えます。一方、delete_section はそのサブツリー全体を削除します。どちらのセクション操作にも、正規の v2 見出しポインターが必要であり、subtreeHash を検証します。

5つの画像ツールのいずれも、Markdown を変更したり、Markdown インデックスの同期をスケジュールしたりしません。

kb_patch の例

MCP メソッドは単一の request オブジェクトを受け取ります。その中の operations は、単一の操作を適用する場合でも常に配列です。新しい具体的な要素ポインターには、kb_read、kb_search、または kb_outline が返す正規の v2 アンカーを使用してください。従来の logical~selfHash アンカーは、ナビゲーションと Self の変更には引き続き使用できますが、replace_section には v2 のサブツリーハッシュが必要です。kb_patch は expectedSourceHash を受け付けません。

replace_element を使用すると、編集可能な Markdown 要素をちょうど 1 つ置き換えられます。見出しの場合、変更されるのは見出し自体のみで、既存のセクション本文はそのまま保持されます。置換内容は、解析後に編集可能な要素がちょうど 1 つになる必要があり、見出しを置き換える場合は同じ見出しレベルを維持する必要があります。非推奨のエイリアスである replace も、同じ検証条件で引き続きサポートされています。

replace_section を使用すると、見出しセクション全体をまとめて書き換えられます。対象には、selfHash と subtreeHash の両方を含む正規の v2 見出しアンカーが必要です。置換範囲はその見出しから始まり、対象のレベル以下の見出しが次に現れる位置、または EOF までのすべてのネストされた内容を含みます。置換内容は同じレベルの見出しで始まり、その後に含められる見出しは対象より深いレベルのものに限られます。

1 つの要素を置き換える場合：

{
  "request": {
    "path": "chapter.md",
    "operations": [
      {
        "kind": "replace_element",
        "pointer": "1.2.p2~8f41c721d904a8bc~8f41c721d904a8bc",
        "markdown": "New paragraph."
      }
    ]
  }
}

セクション全体を置き換える場合：

{
  "request": {
    "path": "chapter.md",
    "operations": [
      {
        "kind": "replace_section",
        "pointer": "1.2~0123456789abcdef~fedcba9876543210",
        "markdown": "## Updated section\n\nNew body.\n\n### Nested heading\n\nNested body."
      }
    ]
  }
}

後に挿入する場合：

{
  "request": {
    "path": "chapter.md",
    "operations": [
      {
        "kind": "insert_after",
        "pointer": "1.2.p2~8f41c721d904a8bc~8f41c721d904a8bc",
        "markdown": "Additional paragraph."
      }
    ]
  }
}

削除する場合：

{
  "request": {
    "path": "chapter.md",
    "operations": [
      {
        "kind": "delete",
        "pointer": "1.2.p2~8f41c721d904a8bc~8f41c721d904a8bc"
      }
    ]
  }
}

サポートされる kind の値は、replace、replace_element、replace_section、delete_section、insert_before、insert_after、delete です。replace、replace_element、replace_section、および挿入操作には markdown が必要ですが、削除操作には不要です。特殊な document ポインターにはハッシュがなく、ドキュメントの境界で insert_before または insert_after とともに使用できます。有効な単一要素の replace リクエストは引き続き互換性がありますが、replace による複数要素の置換は意図的に拒否されます。その場合は replace_section またはその他の明示的な操作を使用してください。

ファイル内の別の場所に無関係な編集があっても、対象の selfHash が有効であれば、Self の変更は無効になりません。上部へのコンテンツの挿入によって対象の位置が変わった場合、同じ要素種別と完全一致する selfHash によって現在の要素がちょうど 1 つ特定できる場合に限り、kb_patch は対象を再特定します。さらに replace_section は元の subtreeHash も検証するため、対象セクション範囲内の編集（未加工／非インデックス化の Markdown を含む）は、上書きされずに拒否されます。

現在の対象範囲

現在のバージョンは、インデックス化されたローカルの Markdown と通常の画像アセットをサポートしています。5 つの画像ツールはすべて knowledgeBase.root を境界として使用し、保存先のデフォルトは images/ です。ChatGPT からのリモートアクセスは OpenAI Secure MCP Tunnel を通じてサポートされています。この機能は、既存のローカル stdio サーバーを外部から起動し、ブリッジ接続します。

PDF／DOCX／OCR、任意のバイナリのアップロード、画像の埋め込み／検索、画像のリサイズ／形式変換／サムネイル生成、Markdown への画像の自動挿入、メディアデータベース、Web UI、Git 履歴のインデックス化、リモート HTTP による直接 MCP トランスポート、アプリケーションレベルの認証、マルチユーザーモード、CRDT、自動マージは、現在の対象範囲外です。

アドレス指定可能な Markdown リスト項目と不透明な引用ブロック

kb_read は、個々のリスト項目を list_item として、li1、1.li2、1.li2.li1 および通常の 2 つのハッシュアンカー接尾辞で公開します。親テキストには、入れ子の項目のテキストは含まれません。replace_element（および非推奨の別名 replace）は、項目自身のソース内容を最初の入れ子の子の前まで変更し、すべての子孫と、その後にある親自身の未変更部分を保持します。この操作では selfHash を確認します。明示的な replace_subtree または delete は、サブツリー全体を置換または削除し、現在の両方のハッシュを必要とします。隣接する位置への挿入ではセルフハッシュを確認し、互換性のあるリストマーカーを持つ、ソース上のインデントが一致した兄弟項目を 1 つ受け付けます。空行も順序付きリストの番号も、暗黙に正規化されません。

単独の Markdown 引用は、内部の Markdown（> - item を含む）にかかわらず、qN または 1.qN で表される 1 つの不透明な block_quote です。読み取り、検索、削除、その前後への挿入、または全体の置換のみが可能です。リストや引用の内部で非表示になった以前の段落ポインターは、再読み込みする必要があります。

リスト項目の編集では、半開区間の正確なソース範囲を使用します。サブツリーにはすべての子孫が含まれますが、親自身のテキストは子ではないソースセグメントのみで構成されます。replace_element は、親自身の連続した先頭部分を置換し、入れ子の項目と、その後にある親自身のソースを保持します。replace_subtree はサブツリー全体を置換します。delete は、終端の改行がある場合、それも削除対象に含めます。insert_after はすべての子孫の後に挿入します。AST のシリアライズやドキュメント全体の空白正規化は行われず、変更されていないソースのバイト列（BOM や混在した EOL を含む）は保持されます。

リスト項目の挿入または置換では、対象と同じ物理インデントと互換性のあるマーカースタイルの項目を1 つ指定する必要があります（順序付きリストのマーカー番号は異なっていても構いません）。replace_element は子項目のない項目を受け付けます。既存の子項目は保持され、安全なソース接頭部分を証明できない場合は処理を安全に中止します。入れ子のリストを意図的に変更するには、現在の subtreeHash を指定して replace_subtree を使用します。replace_subtree と兄弟項目の挿入では、入れ子の項目を使用できます。Markdig が新しい項目に属すると判定した場合は、コード、HTML コメント、その他の Markdown ブロックも新しい項目内に含められます。新しいサブツリーの外部にある独立したブロックは拒否されます。たとえば、コメントによってリストが分割されている場合、トップレベル項目を - Updated\n\n で置換することはできません。Markdig がコメントを項目に属すると判定する場合は、- Updated\n\n が許可されます。同様に、引用の断片は、隣接部分を取り込まずに、ちょうど 1 つの不透明な引用を形成する必要があります。

サーバーは書き込み前に、変更後の結果全体を再解析します。既存の要素、アドレス指定できないブロック、リストコンテナーの所属、親子関係、隣接境界が維持されている必要があります。曖昧または重複する編集（1 つの kb_patch 内の複数操作を含む）は、構造エラーとして原子的に失敗し、ソースファイルは変更されません。サポートされていないインデント、リストの分割・統合、引用の境界の曖昧さは、自動整形せず、意図的に拒否されます。

検索ポインターと読み取りヒントが示すのは、最初のチャンク要素であり、リスト項目内の一致箇所そのものとは限りません。チャンク化バージョン 5 では、派生インデックスの明示的な再構築が必要です。kb_reindex(force=true) または CLI の --reindex --force を使用してください。Markdown の移行は行われません。

セマンティック Markdown テーブル

単独の GFM パイプテーブルは、セクション内の tN ポインターを持つアトミックな table 要素として表示されます。テーブルのハッシュ付きポインターを指定して kb_read を呼び出すと、table.columns（名前、インデックス、配置）と table.rows（0 から始まるデータ行インデックスと表示されるセルテキスト）を取得できます。通常のドキュメントページングでは、構造化された投影は重複して表示されません。

新しい kb_edit_table ツールは、path、tN~selfHash~subtreeHash の形式の現在の pointer、および次の 7 つのアクションのいずれかを受け取ります：update_cells、insert_row、delete_row、insert_column、delete_column、rename_column、set_alignment。例：

{
  "path": "recipes.md",
  "pointer": "1.t1~<selfHash>~<subtreeHash>",
  "action": "update_cells",
  "updates": [
    {
      "where": { "column": "Product", "equals": "Chicken" },
      "column": "Price",
      "value": "20"
    }
  ]
}

行の値が一意の場合は where を、ヘッダーが一意の場合は column を優先してください。それ以外の場合は、数値の rowIndex と columnIndex を使用します。検索は完全一致で、大文字と小文字を区別します。update_cells は複数の更新をアトミックにまとめて実行します。値は既定でリテラルの text として扱われ、Markdown は安全にエスケープされます。valueFormat=markdown を指定すると、意図的なインライン書式を使用できます。新しく挿入した行の値と列の既定値はリテラルテキストです。

成功時のレスポンスには、新しいテーブルの pointer、更新された sourceHash、インデックス同期のステータスが含まれます。編集を連続して行う場合は、返されたポインターを再利用してください。CONFLICT が発生した場合は、テーブルを再読み込みしてください。余分な無視対象の物理セルがあるテーブルは編集できません。無関係な Markdown は保持され、既存のアトミックなワークスペースライターが使用されます。コード、リスト、引用ブロック内のテーブルには、独立したテーブルポインターはありません。テーブル全体を削除するには、kb_patch を使用してください。

テーブルの解析により、派生インデックスの形式はチャンク化ツールのバージョン 6 に変わります。互換性のないインデックスは、kb_reindex(force=true) または CLI の --reindex --force で再構築してください。Markdown ファイルの移行は不要です。

Markdown リンクグラフ

kb_reindex の後、kb_links を使用すると、明示的な Markdown 参照をどちらの方向からも参照できます（または深さを制限したグラフ探索を実行できます）。リンク先のドキュメントが見つからない場合の診断にも利用できます。このグラフはセマンティックな関係を推測せず、埋め込みなしで動作します。Markdown リンクグラフと MCP の例を参照してください。