Grounded Docs MCP Server: ローカル文書インデックスでAIの参照先を固定する
Grounded Docs MCP Server: Open-Source Alternative to Context7, Nia, and Ref.Tools
ひと目でわかる
- これは何？
- 公式ドキュメントを手元に取り込み、バージョン単位で検索させるMCPサーバー。CLIとWeb UIの二系統と、埋め込みモデルが任意である点が設計の要で、検索精度はそこに依存する。
- 誰に向いている？
- 採用すべきなのは、社内ネットワークからコードやドキュメントを出せない制約があり、かつNode.js 22以降を用意できるチームである。逆に、数十のライブラリを横断して常に最新のドキュメントを引きたいだけの用途では、ホスト側でインデックスを維持してくれる商用サービスに軍配が上がる。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 18 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
どのバージョンのドキュメントを読ませるかという問題
AIコーディングアシスタントが古いAPIを提案する原因は、モデルの知識が学習時点で止まっていることにある。Grounded Docs MCP Serverが解こうとしているのはこの一点で、READMEの冒頭でも「AI hallucinations and outdated knowledge」への対処だと明記されている。対象読者は、MCP対応クライアントをすでに使っている開発者と、その設定を管理する立場のエンジニアだ。
特徴的なのは、単にWebを検索させるのではなく、利用中のバージョンに対応したドキュメントをインデックスとして手元に置く設計を取っている点である。READMEは「Queries target the exact library versions in your project」とうたっており、検索対象は実行時に取得したWebページではなく、あらかじめ取り込んだインデックスになる。つまり鮮度はクロール時点で決まり、モデルの学習時点とは切り離される。
インデックスを作る側と引く側が分かれている
このツールは大きく二つの使い方を想定している。一つはCLIで、エージェントやスクリプトから呼ぶ前提の使い捨てコマンド群である。もう一つはMCPサーバーとして常駐させ、ClaudeやCline、Copilot、Gemini CLIといったクライアントから接続する形だ。READMEの表現では「For agents and scripts, the CLI is usually the simplest way」とされ、CLIが先に紹介されている。
データの流れは素直である。scrapeで対象URLやリポジトリ、ローカルフォルダを取り込み、抽出したテキストをインデックスに格納する。searchはそのインデックスに対して問い合わせを投げ、fetch-urlはインデックスを介さず単一ページをMarkdownとして取得する。取り込み元はWebサイト、GitHub、npm、PyPI、ローカルファイル、zipアーカイブと幅広く、対応形式にはPDF、Office文書、EPUB、Jupyter Notebook、そして90以上のソースコード言語が含まれるとREADMEは説明している。
常駐させた場合の既定ポートは6280で、Web UIも同じポートで開く。MCPクライアント側はsse形式でhttp://localhost:6280/sseを指す設定を書く。
CLIの実際の呼び出し方と出力の扱い
READMEに載っているコマンドはそのまま使える形で示されている。Node.js 22以降が必要で、npx経由で最新版を呼ぶ。
npx @arabold/docs-mcp-server@latest scrape react https://react.dev/reference/react
検索はインデックス名を指定して行う。
npx @arabold/docs-mcp-server@latest search react "useEffect cleanup" --output yaml
単一ページをMarkdownで欲しいだけならfetch-urlを使う。
npx @arabold/docs-mcp-server@latest fetch-url https://react.dev/reference/react/useEffect
出力の設計はエージェント用途を意識している。構造化コマンドは非対話実行時に既定でJSONをstdoutへ出し、--output json|yaml|toonで形式を選べる。fetch-urlのようなプレーンテキスト系コマンドは本文をstdoutに残す。ログや診断は共有ロガー経由でstdoutから追い出されるため、パイプでJSONを食わせるスクリプトが壊れにくい。--quietでエラー以外の診断を抑制し、--verboseでデバッグ出力を有効にする。
Dockerで動かす場合は、/dataと/configの2つのボリュームをマウントし、--protocol http --host 0.0.0.0 --port 6280を渡す例がREADMEに載っている。
埋め込みモデルを省くと検索はどう変わるか
READMEは埋め込みモデルの利用を「optional」としつつ、「dramatically improves search quality by enabling semantic vector search」と書いている。この一文が実運用上の分岐点である。埋め込みを設定しなければベクトル検索は働かず、検索は語句の一致に寄った挙動になる。
有効化は環境変数で行う。OpenAIを使う場合はOPENAI_API_KEYを渡した状態でサーバーを起動するだけでよい。
OPENAI_API_KEY="sk-proj-..." npx @arabold/docs-mcp-server@latest
OpenAI以外にOllama、Gemini、Azureも設定できるとREADMEは案内しており、詳細はdocs/guides/embedding-models.mdに分離されている。Ollamaを選べば外部APIへ文書を送らずに済むため、READMEが掲げる「Runs entirely on your machine; your code never leaves your network」という説明と整合させやすい。ただし埋め込みを有効にした時点で、選んだプロバイダ次第ではインデックス対象のテキストが外部へ出る。ここはREADMEのプライバシー記述をそのまま受け取らず、プロバイダごとに判断する必要がある。
llms.txtの探索とハッシュルーティングSPAへの対応
Webスクレイピング周りには、他のドキュメント取り込みツールと差がつく仕様がある。Web取得とリフレッシュの際、通常のクロールの前にドキュメントのサブパスとサイトルートでllms.txtを探す。見つかればそこに列挙されたリンクを追加のクロールシードとして使い、その経路で見つかったページは/guide/index.html.mdや/page.html.mdのような.md版URLを優先し、なければ元ページに落ちる。リクエストのAcceptヘッダも既定でtext/markdownを先頭にした内容交渉を行う。
ハッシュルーティングのSPAは別扱いになる。URLが#/guideのようになるサイトでは--preserve-hashes、MCP側のpreserveHashes、Web UIの「Preserve Hash Routes」チェックボックスで明示的に有効化する。有効にした状態でscrapeMode=fetchを指定すると、プレーンなfetchではクライアント側のハッシュルートを評価できないため、スクレーパは自動的にPlaywrightへジョブを昇格させる。リフレッシュは既定で保存済みのpreserveHashes設定を再利用し、CLIとWebのリフレッシュ入口から明示的に上書きできる。
注意点として、READMEはこれを通常サイトに使うなと釘を刺している。通常のサイトではハッシュ断片はページ内アンカーに使われるため、有効化すると取得結果が壊れる。
向かない場面と、Context7系サービスとの違い
このツールが向かないのは、インデックスの管理を自分でやりたくない場合である。READMEはContext7、Nia、Ref.Toolsのオープンソース代替だと位置づけているが、違いは運用責任の所在にある。商用のホスト型サービスは、多数のライブラリについて向こう側がインデックスを更新し続ける。利用者はURLを指定するだけでよく、古くなったら向こうが直す。Grounded Docsは逆で、scrapeした時点の内容がインデックスになり、更新はリフレッシュ操作を誰かが実行しない限り起きない。監視も再クロールのスケジュールも自前になる。
もう一つの制約は実行環境である。Node.js 22以降が前提で、Dockerを使うにしても/dataと/configの永続ボリュームを用意する必要がある。ハッシュルーティングのサイトを扱うとPlaywrightが動くため、ヘッドレスブラウザを動かせる環境が要る。CIのような短命なコンテナで使うなら、インデックスを毎回作り直すコストを見込むことになる。
検索品質の評価手段は用意されている。docs/guides/benchmarking.mdに、IR指標とLLMによる判定を組み合わせたベンチマークの前提条件、実行方法、結果の読み方がまとまっているとREADMEは説明している。埋め込みモデルを変えたときに効くかどうかを、体感ではなく数値で見たい場合の入口になる。
ライセンスと更新コストの見積もり
ライセンスはMITで、リポジトリはアーカイブされていない。直近のリリースはv3.1.0が2026年8月29日、v3.0.1が8月14日、v3.0.0が8月8日で、メジャー更新のあとに短期間でパッチが続いた形になっている。v3系に入ってからの変更点の内容までは手元の資料からは確認できないため、v2から上げる場合はリリースノートを直接読む必要がある。
運用コストとして見落としやすいのは、インデックスの再構築と埋め込み生成にかかる時間と、プロバイダのAPI利用料である。OpenAIの埋め込みを使うなら、インデックス対象の文書量に比例して課金が発生する。Ollamaを選べばAPI料金は消えるが、その分の計算資源は自前で持つことになる。
ライセンス上の注意としては、MITであるのはこのサーバー本体についてであり、取り込む対象のドキュメントの利用条件は別問題である。社内文書をインデックスに入れる場合、その文書の扱いを定めるのは自組織の規程であって、このプロジェクトのライセンスは関係しない。
導入前に確かめる3つのこと
最初に確認するのは、対象ドキュメントサイトがllms.txtを公開しているかどうかである。公開していればクロールの種が増え、.md版URLが優先されるため、取得結果の質が変わる。次に、対象サイトが#/形式のハッシュルーティングを使っていないか。使っているなら--preserve-hashesが必要になり、Playwrightが動く環境を用意することになる。最後に、埋め込みモデルをどのプロバイダで動かすか。OPENAI_API_KEYを渡すのか、Ollamaを立てるのかで、検索品質とデータの出所が同時に決まる。
これらを決めずにnpx @arabold/docs-mcp-server@latestを起動しても、Web UIは開き、インデックスは作れる。ただし埋め込みなしの検索結果を評価して「精度が足りない」と判断してしまうと、原因を取り違える。まずOPENAI_API_KEYかOllamaのどちらかを用意した状態でscrapeとsearchを1回ずつ流し、そのうえでdocs/guides/benchmarking.mdの手順に沿って数値を取る順序が素直である。
編集部の結論
採用すべきなのは、社内ネットワークからコードやドキュメントを出せない制約があり、かつNode.js 22以降を用意できるチームである。逆に、数十のライブラリを横断して常に最新のドキュメントを引きたいだけの用途では、ホスト側でインデックスを維持してくれる商用サービスに軍配が上がる。導入前に確認すべきは、対象ドキュメントサイトがllms.txtを公開しているか、ハッシュルーティングを使っていないか、そして埋め込みモデルを動かすAPIキーかOllamaのどちらを用意できるかの3点である。このうち埋め込みを省いた場合、検索はキーワード一致に近い挙動になり、search react "useEffect cleanup"のような短い問い合わせでは取りこぼしが出る。
コミュニティノート