SiteMCP(sitemcp)は、指定したWebサイトをクロールして本文をMarkdownに変換し、MCPサーバーとしてClaudeなどのAIアシスタントに渡すコマンドラインツールです。作者はryoppippi氏で、2025年4月に公開されました。2026年4月12日に作者がREADME冒頭でアーカイブを告知し、npmの最新版は2025年8月11日公開の0.5.9のまま止まっています。この記事では、v0.5.9のソースとMCPクライアントからの実行結果をもとに、登録手順と全オプション、localhostの社内サイトで起動に失敗するなどのつまずきやすい挙動、いま使ってよい場面と代替手段を説明します。
まとめ:SiteMCPの現状と使いどころ
- SiteMCPは「サイト全体を取得→本文抽出→Markdown化→MCPの2ツールで返す」だけのCLIで、ローカルのstdioで動きます。設定画面や常駐サーバーの機能はありません。
- 使い方は
npx sitemcp <URL>を起動コマンドとしてClaude DesktopやClaude CodeのMCP設定に登録するだけです。よく使うオプションは-m(取得範囲の絞り込み)と-t(ツール名の付け方)です。 http://localhostのルートURLは「Invalid URL」で起動に失敗し、.co.jpのサイトはツール名がindexOfCoになります。/docs/のようなパスを付けて-t pathnameを指定するか、127.0.0.1や-t subdomainに切り替えて回避します。- キャッシュはURLだけで決まり、
-mを変えても古い結果が返ります。更新するには~/.cache/sitemcp/のファイルを消して起動し直します。 - 2026年4月に作者がアーカイブを告知し、静的ドキュメントをMCPで渡すこと自体を「an anti-pattern」と書いています。新規採用の前に、npm同梱のドキュメントやllms.txtで足りないかを確かめるのが先です。
SiteMCPの仕組み:取得したページを2つのMCPツールで返すCLI
SiteMCPはegoist氏のsitefetch(サイトを丸ごと取得して1つのテキストファイルに保存するツール)をフォークし、出力先をファイルからMCPサーバーに置き換えたものです。MCPそのものの仕組みはMCP(Model Context Protocol)の定義と仕組みの解説にまとめています。
起動時の処理:クロール・本文抽出・Markdown化・キャッシュの流れ
起動するとまず指定URLを取得し、ページ内の<a>から同じホストへのリンクだけを拾って順に辿ります(既定の同時接続数は3)。各ページはJavaScriptを実行しない仮想DOM(happy-dom)に読み込み、MozillaのReadabilityで本文を抜き出してturndownでMarkdownへ変換します。結果はパス名をキーにしたJSONとして ~/.cache/sitemcp/ に保存され、2回目以降の起動はクロールせずこのファイルを読みます。
全ページの取得が終わってからMCPの通信を始めるため、ページ数の多いサイトほどクライアント側の起動待ちが長くなります(READMEが登録前の事前実行を勧める理由)。
公開される2つのツール:indexOf〜とgetDocumentOf〜
MCPクライアントから見えるツールは2つだけで、名前にはURLから作った語が入ります。https://vite.dev なら indexOfVite と getDocumentOfVite です。
| ツール | 引数 | 返す内容 |
|---|---|---|
| indexOf〜 | max_length, start_index | パス名とタイトルの一覧 |
| getDocumentOf〜 | subpath, max_length, start_index | 1ページ分のMarkdown本文 |
AIはまず一覧を取り、読みたいページのパスを指定して本文を取ります。本文は既定で2,000文字ずつ返り、残りの量はremainingContentLengthで示されます。2026年9月27日の実行では、Viteの入門ページ(/guide/)は1回目に2,000文字が返って残りが8,881文字だったので、既定の2,000文字ずつ取得するなら、本文取得ツールの呼び出しは合計6回になります。
SiteMCPの実行環境とClaudeへの登録手順
SiteMCPの事前起動とキャッシュ作成
事前のグローバルインストールは不要で、npx・bunx・pnpxのいずれかでその場で実行できます。常用するならnpm i -g sitemcpで入れても構いません。package.jsonにenginesの指定は無く、対応するNode.jsの版は明記されていません。
npx sitemcp https://vite.dev -m "/guide/**" --concurrency 10
ターミナルで実行すると、取得が終わった時点でキャッシュが書き込まれ、標準入出力での待ち受けに入ります。Ctrl+Cで止めてから登録すれば、クライアントの起動時はキャッシュを読むだけで済みます。
Claude Desktop・Claude CodeへのMCP登録設定
Claude Desktopでは、READMEの例どおり設定ファイルのmcpServersに起動コマンドを書きます。
{
"mcpServers": {
"daisy-ui": {
"command": "npx",
"args": ["-y", "sitemcp", "https://daisyui.com", "-m", "/components/**"]
}
}
}
Claude Codeではclaude mcp addの--以降に同じコマンドを渡します。スコープは既定でlocal(そのプロジェクトの自分だけ)です。
claude mcp add vite-docs -- npx -y sitemcp https://vite.dev -m "/guide/**"
通信方式はstdioだけで、HTTPで待ち受けるモードはありません。リモートから共有サーバーとして使う用途には向きません。エージェントにMCPサーバーをつなぐときの権限の考え方はMCPサーバーの作り方とAIエージェントへの接続手順で扱っています。
複数サイトのサーバー別登録とキャッシュ共有の制約
1つのSiteMCPが扱えるのは起動時に渡した1つのURLだけです。複数のドキュメントを読ませたいときは、サイトごとに別のサーバー名で登録します。
claude mcp add vite-guide -- npx -y sitemcp https://vite.dev -m "/guide/**"
claude mcp add daisyui -- npx -y sitemcp https://daisyui.com -m "/components/**"
同じURL(例:https://vite.dev)を起点に-mだけ変えて2つ登録すると、どちらもツール名がindexOfViteになり、キャッシュファイルも同じvite-dev.jsonを共有します。後で起動した側にも先に取得した範囲が返るため、この分け方は成り立ちません。1つのサーバーに-mを複数並べてまとめてください。
SiteMCP v0.5.9のオプション一覧と既定値
sitemcp --help に出るオプションは次の7つです(--cacheと--no-cacheは1組として数え、ヘルプ・バージョン表示は除く)。
| オプション | 既定値 | 役割 |
|---|---|---|
-c, --concurrency |
3 | 同時リクエスト数 |
-m, --match |
なし | 取得するパスをglobで限定(複数可) |
--content-selector |
なし | 本文を探すCSSセレクター |
--limit |
なし | 取得ページ数の上限 |
--no-cache |
キャッシュ有効 | キャッシュを読まず書かない |
-t, --tool-name-strategy |
domain | ツール名の元(subdomain/domain/pathname) |
-l, --max-length |
2000 | 1回に返す上限 |
-mはmicromatchのglobでパス名と照合します。--content-selectorは、Readabilityがナビゲーションや広告を本文と取り違えるサイトで、本文の入った要素(例:".content")を指定するときに使います。-lは本文では文字数の上限ですが、一覧(indexOf〜)では返す件数の上限として使われるため、既定の2,000のままなら一覧は2,000ページ分まで一度に返ります。
ツール名の決まり方と、localhost・.co.jpで起きる問題
ツール名は-tで選んだURLの一部をパスカルケースにして作ります。domainはホスト名を「.」で区切って末尾(TLD)を除いた最後の語、subdomainはラベルが3つ以上あるときの先頭の語、pathnameはパス全体です(v0.5.9のutils.ts)。この規則のため、ホスト名の形によっては意味のない名前になったり、起動そのものに失敗したりします。
-t(tool-name-strategy)ごとのツール名の例
READMEの例と、2026年11月4日にmacOS・Node.js v26.5.0で[email protected]をMCPクライアントから起動して確かめた結果です。
| 起点URL | -t | 一覧ツールの名前 |
|---|---|---|
| https://vite.dev | domain | indexOfVite |
| https://react-tweet.vercel.app/ | subdomain | indexOfReactTweet |
| https://jprs.co.jp/ | domain | indexOfCo |
| https://jprs.co.jp/ | subdomain | indexOfJprs |
| http://127.0.0.1:18731/ | domain | indexOf0 |
| http://localhost:18731/ | domain | 起動失敗 |
| http://localhost:18731/ | subdomain | 起動失敗 |
| http://localhost:18731/guide/a.html | pathname | indexOfGuideAHtml |
.co.jpや.go.jpのような属性型JPドメイン名では、TLDの「jp」を除いた直前のラベル「co」「go」が採用されます。google.co.jpがcoになる不具合はIssue #12で報告され、未解決のままです。AIはツール名と説明文を見てどのツールを呼ぶかを決めるので、indexOfCoのような名前ではサイトの中身が伝わりません。日本の企業サイトや官公庁サイトを登録するときは、wwwの付かないホスト名なら-t subdomainで社名などが名前に入ります(jprs.co.jpはindexOfJprs)。www.で始まるホスト名ではsubdomainが「www」になるため、-t pathnameでパスから名前を作ります。
名前の長さにも目安があります。MCP仕様(2025-11-25版)のツール定義は、ツール名を1〜128文字にすべき(SHOULD)としています。pathnameは深い階層ほど名前が長くなり、本文取得側はgetDocumentOfの13文字が前に付くので、階層の浅いURLを起点にするのが無難です。
localhostの社内・ローカルサイトを取り込む手順
SiteMCPは手元のマシンから直接HTTPでページを取りに行くので、手元でビルドしたドキュメントや、VPN越しに見える社内サイトも対象にできます。ただしhttp://localhost:<ポート>/を既定の-t domainで渡すと、ホスト名に「.」が無いため名前を作れず、Error: Invalid URLで終了します。クライアント側には「Connection closed」とだけ出ます。この判定は全ページの取得とキャッシュの書き込みが終わった後に行われるので、キャッシュファイルだけが残ります。http://docs/のような「.」の無い社内ホスト名も同じです。
回避策は2つあります。
localhostを127.0.0.1に書き換える:起動はしますが、ツール名はindexOf0になります。- 起点に意味のあるパスを付けて
-t pathnameを指定する:http://localhost:8080/docs/ならindexOfDocsになり、AIにも中身が伝わります。
claude mcp add local-docs -- npx -y sitemcp http://localhost:8080/docs/ -t pathname
リクエストに付くのはuser-agentヘッダーだけで、Cookieや認証ヘッダーを渡す手段はありません。ログインが必要な社内Wikiは取得できず、取れるのはネットワーク上で認証なしに見えるページだけです。
v0.5.9の実装から分かる注意点
ここからは、2026年9月27日に同じ環境で[email protected]を実行し、v0.5.9タグのソースと突き合わせて確認した挙動です。READMEには書かれていません。
URL単位のキャッシュ再利用と取得範囲変更時の削除
キャッシュファイル名はURLから作られ(https://vite.dev なら vite-dev.json)、-mや--limitはファイル名にも照合にも使われません。-m "/guide/**"で一度起動したあと-m "/blog/**"に変えて起動すると、一覧には/guide/配下のページがそのまま返り、/blog/配下は1件も入りませんでした。有効期限も無いため、元のドキュメントが更新されても自動では取り直しません。
取得範囲を変えたとき、または元サイトが更新されたときは、~/.cache/sitemcp/の該当ファイルを削除してから、キャッシュを有効にした通常起動で取り直します。--no-cacheはキャッシュを読まず書きもしないため、既存ファイルの更新には使えません。
キャッシュ用ディレクトリ未作成時のENOENTと再起動
キャッシュ用ディレクトリの作成(fs.promises.mkdir)の完了を待たずにファイルの書き込みを始めるため、ディレクトリがまだ無い状態の初回起動でENOENT: no such file or directoryを出して終了することがあります。XDG_CACHE_HOMEを存在しない場所に向けて試すと5回中5回この終了になり、クライアント側には「Connection closed」とだけ表示されました。落ちた時点でディレクトリはできているので、もう一度起動すれば動きます。登録直後に接続失敗が出たら、設定を疑う前に再起動を1回試してください。
JavaScript描画への非対応とShift_JIS・EUC-JPの文字化け
取得時はJavaScriptの実行を無効にしているため、本文をブラウザ側で描画するSPA型のドキュメントサイトは空に近い内容になります(Issue #7「Support SPA」は未解決)。また、HTMLを常にUTF-8として読むので、Shift_JISやEUC-JPで配信される日本語ページは文字化けします。Content-Typeに文字コードの指定が無いShift_JISの個人サイトを--limit 3で取得したところ、一覧のタイトルは全件が「�」の羅列でした。同じ不具合はIssue #24で報告され、未解決です。
–limitの超過と、-m指定時の取りこぼし
--limitは保存済みページ数を見てから次を取りに行くため、同時取得中の分だけ上限を超えます。https://vite.dev -m "/guide/**" --limit 5で起動すると7ページ保存されました。-mを指定しても起点URLのページはパターン照合を省くため、本文の抽出に成功すれば取得対象に入ります。一方、-mに一致しないページからはリンクを辿らないので、起点から目的のページへ至る経路に、パターンに一致しない中間ページがあると取りこぼします。sitemap.xmlは読まず(対応の提案はIssue #19・#20で未実装)、robots.txtの確認もしません。取得先の利用規約やクロールの負荷は、スクレイピングとクローリングの違いと実装・法務の判断と同じ観点で利用者が判断します。
2026年4月のアーカイブ告知と配布状況
作者は2026年4月12日のコミットで、GitHubリポジトリのREADME冒頭に「This repository is archived.」と告知しました。公開当時はコーディングエージェントの能力が低く、LLMのWeb検索も当てにならなかったためサイト丸ごとの取得に意味があったが、その後コミュニティは静的ドキュメントをMarkdownで配る、npmパッケージで配る、最後の手段としてWeb検索を使う、という簡素な方法に収束した、というのが理由です。そのうえで、静的ドキュメントをMCPで渡すことは「an anti-pattern」になったと書いています。なお、GitHubの設定上のアーカイブ(読み取り専用化)はされておらず、READMEでの告知にとどまります。
| 項目 | 値(2026年11月4日時点) |
|---|---|
| npm最新版 | 0.5.9(2025-08-11) |
| 最初の公開 | 0.1.0(2025-04-07 UTC) |
| 公開中の版数 | 27 |
| 直近30日のダウンロード | 1,528(2026-10-05〜11-03) |
| GitHubスター | 761 |
| ライセンス | MIT |
本体のコードは0.5.9から変わっておらず、前節の不具合は直らない前提で扱います。一方、MCPの通信部分は同梱ではなく、@modelcontextprotocol/sdkを^1.17.2の範囲で外部参照しています。2026年11月4日に空のディレクトリへ[email protected]だけを入れると、SDKは1.32.2が入りました。npxで新しく取得する環境ではSDK側の修正が反映されますが、以前にグローバル導入した環境やnpxのキャッシュには、古い版が残ることがあります。SDKの1.x系では2026年10月に脆弱性の修正が公表されており、急いで更新すべきなのはHTTPで公開するサーバーと、信頼できないサーバーへ接続するクライアントです。対象版はMCP TypeScript SDKの脆弱性:2026年10月の7件の対象版で確認できます。stdio専用のSiteMCPでも、npm ls @modelcontextprotocol/sdkで依存SDKの版を確認し、該当する脆弱性の修正版と照合してください。
SiteMCPの代替手段と、いま使ってよい場面
作者が勧めるnpm同梱ドキュメントとllms.txtとの比較
作者は2025年12月14日のブログ「ドキュメントをnpm packageとしてpublishしよう」で、MCPでドキュメントを渡す方法の問題を挙げています。コーディングエージェントに登録できるMCPサーバーの数には上限があること、多く登録すると定義だけでcontext windowを圧迫すること、一度に返せる量に限りがあるためやり取りが何度も要る「N+1問題」が起きることです。SiteMCPのページ送り(start_index)もその例だと作者自身が書いています。
代わりに勧めているのは、ドキュメントをnpmパッケージに同梱してnode_modulesから読ませる方法で、実例としてbun-types、@gunshi/docs、@praha/byethrow-docsを挙げています。利用中のライブラリの版に合った文書が手元に置かれる点が、SiteMCPのように公開中の最新サイトを取得する方式との違いです。サイト側がLLM向けのMarkdownを置くllms.txtについては、作者は同じブログで「毎回リモートにあるドキュメントを参照するのに時間もコストもかかる」ことと、版ごとのドキュメントが無いと古い版のライブラリを使うときに情報が食い違うことを、MCPと共通の問題として挙げており、npm同梱の方を勧めています。llms.txtの仕様と書き方はllms.txtの書き方・設置方法とv2の変更点で解説しています。
手順や規約をエージェントに覚えさせたいなら、ドキュメント取得ではなくAgent Skills(SKILL.md)の仕組みで渡せます。社内の大量文書を検索させるならMCPよりRAGの領域で、役割分担はMCPとRAGの違いと使い分けで整理しています。GitHubのリポジトリを要約させたい場合は、コードからWikiを生成するDeepWiki-Openが合います。社内ドキュメントをエージェントの業務フローに組み込む設計まで含めて検討するなら、AIエージェント開発の支援もご相談いただけます。
SiteMCPを今から使ってよい場面・避けるべき場面
使ってよいのは、llms.txtもnpm同梱ドキュメントも無く、サーバー側でHTMLを返すUTF-8のドキュメントサイトを、手元のClaude DesktopやClaude Codeで一時的に読ませたいときです。-mで数十ページ程度に絞り、キャッシュの消し方とツール名の付け方を押さえていれば、v0.5.9でも動きます。
避けるべきなのは次の場面です。
- SPA型のドキュメントサイトや、Shift_JIS・EUC-JPの日本語サイト(本文が取れない・化ける)
- 数千ページ規模のサイト(全件取得まで待ち受けが始まらず、Issue #13ではメモリ不足で停止した報告がある)
- ログインが必要な社内Wiki(認証情報を渡せない)
- チームで共有する常設のドキュメント基盤(stdio専用・保守終了・キャッシュの自動更新なし)
保守の止まったツールは業務の前提に組み込まず、個人の調べものに限って使います。
よくある質問
SiteMCPは無料で使えますか?
無料です。MITライセンスのOSSで、npmから誰でも実行できます。APIキーや利用登録もありません。
SiteMCPはログインが必要なページも取得できますか?
取得できません。リクエストに付けるのはuser-agentヘッダー(SiteMCPとリポジトリURL)だけで、Cookieや認証ヘッダーを渡すオプションはありません。認証なしで見えるページだけが対象です。
取得したドキュメントを最新にするにはどうすればよいですか?
~/.cache/sitemcp/にあるURL名のJSONファイルを削除してから起動し直します。キャッシュに有効期限は無く、削除しない限り初回に取得した内容が返り続けます。
localhostで起動すると「Connection closed」になるのはなぜですか?
既定の-t domainがホスト名の「.」を手がかりにツール名を作るため、localhostでは名前を作れずInvalid URLで終了しているからです。127.0.0.1に書き換えるか、/docs/のようなパスを付けて-t pathnameを指定すると起動します。
SiteMCPはアーカイブ後も使えますか?
npmの0.5.9は2026年11月4日時点でも実行でき、MCPクライアントからツール一覧の取得と一覧ツールの呼び出しができました。ただし作者がアーカイブを告知しており、本体の不具合の修正や新しいMCP仕様への追随は見込めません。