sitedoctor

sitedoctor

sitedoctor は、検索での可視性とページ上の健全性を監査するホステッドサービス DrUrls への、小規模なローカルブリッジです。このパッケージは自らクロールを行うのではなく、サービスのリモート MCP エンドポイントの窓口として機能します。上流のツール一覧を取得したままの形でローカルに提示し、各呼び出しを中継して、上流から返された内容をそのまま返します。

実用上、この分離は重要です。スコア、問題のグループ、可視性の判定、修正計画はすべて DrUrls 自身のクロールとデータに基づいているため、sitedoctor 経由で得られる回答は、ローカルで近似したものではなく、サービスからの回答です。このブリッジは独自のスコアリングを追加せず、返却時に内容を書き換えることもありません。

ツール

このビルドで提供するのは、取得した機能のうちラベル付きのサブセットです。実際の取得データで確認された11個のツールのうち、10個を提供します。省略されているツールは hire_tester です。これは人によるテストの有料注文を行うもので、購入の実行はこのプログラムの対象外であるため、意図的に含めていません。テストでも、このツールが存在しないことを検証します。list_tester_offers は引き続き利用できます。カタログの閲覧は読み取り操作ですが、そこからの注文はそうではありません。

• list_tester_offers — 人によるテストのカタログを閲覧します。実機でのモバイル UX、チェックアウトの実行、スクリーンリーダーによる確認、翻訳レビューなどのサービスについて、クレジット価格、所要時間、納品物を確認できます。引数はありません。
• list_sites — 組織内のすべてのサイトと、それぞれの最新の完了済み監査を表示します。スコア、グレード、問題、クロールしたページ数、最終スキャン時刻、スキャンの実行状況を確認できます。引数はありません。
• get_site_report — 1つのサイト（domain が必須）の詳細を表示します。最新のスコア、重大度別の問題数、最も頻繁に発生する問題の種類、ソーシャルネットワークでの存在状況を確認できます。
• find_issues — すべてのサイトの未解決の問題を検索します。または、domain と severity（CRITICAL、HIGH、MEDIUM、LOW、INFO）で絞り込めます。結果はサイトと問題の種類ごとにグループ化され、影響を受けるページ数とその一例が表示されます。
• check_google_visibility — Google が各サイトをインデックスに登録できるかどうかを確認します。直近のクロールで検出された noindex タグ、robots によるブロック、サイトマップのエラー、canonical の問題、リダイレクトチェーン、内部リンク切れを確認できます。特定のサイトを対象にする場合は、domain を指定します。
• get_improvement_plan — 現時点で影響が最も大きい修正項目を、重大度と影響範囲に基づいて順位付けして表示し、修正方法も案内します。domain は省略可能です。
• start_scan — サイトの新しい監査を開始します（url が必須）。必要に応じて組織内にサイトが作成され、上流のプランに設定されたクォータが上流で適用されます。
• get_scan_status — 現在実行中のスキャンと、直近10件の完了または失敗したスキャンを、スコアとエラーとともに表示します。引数はありません。
• generate_report — 1つのサイト（domain）の完全な SEO レポートを作成します。domain を指定しない場合は、組織全体のレポートを作成します。
• free_page_check — 公開されている任意の URL（url が必須）を、アカウントなしで無料で単一ページ監査します。認証が必要なツールで追加される機能を説明する upgrade フィールドも含まれます。

設定

• DRURLS_MCP_URL（省略可能）— 上流エンドポイントを上書きします。既定値は https://drurls.com/mcp です。（この上書き用フックは、今回の再構築でラベル付きで独自に追加したものです。）
• DRURLS_API_KEY（省略可能）— 設定すると、すべての上流リクエストに Authorization: Bearer <key> が含まれます。設定されていない場合は、認証ヘッダーは送信されません。この再構築の基になった、キーなしで取得したデータに合わせた動作です。（ヘッダーの動作は、今回の再構築でラベル付きで独自に追加したものです。レジストリの記録ではリモートに対して Authorization ヘッダーが宣言されていますが、取得時には使用されていませんでした。）アカウント単位のツールは、呼び出し元自身の認証情報を使って上流で提供されます。

転送の仕組み

最初のツール呼び出し時に、クライアントは上流との ストリーミング可能な HTTP セッションを開きます。まず JSON-RPC initialize リクエスト（protocolVersion 2025-03-26、 clientInfo name sitedoctor）を送信し、続いて notifications/initialized 通知を送信し、その後、 呼び出し元の引数を変更せずに含めた tools/call リクエストを送信します。上流が initialize に Mcp-Session-Id ヘッダーを付けて応答した場合、 その値は以後のすべてのリクエストに引き継がれ、セッションは プロセスの実行中、再利用されます。応答は通常の JSON または サーバー送信イベントとして届く場合があります。どちらも読み取られ、 一致する ID を持つメッセージが採用されます。

上流からの成功結果は、上流が設定した isError フラグや、 追加したフィールドも含め、そのまま通過します。JSON-RPC エラー、2xx 以外のステータス、読み取り不能な応答、 または完了できないリクエストなどの失敗は、 テキストが sitedoctor error: で始まる isError 結果として返されます （この表示は、この再構築版独自のラベル付き表現です）。

CLI

各ツールは、JSON 引数文字列を 1 つ受け取るサブコマンドとしても 実行できます（引数を取らないツールの場合は省略します）。

npx @reneturcios/sitedoctor list_sites
npx @reneturcios/sitedoctor get_site_report '{"domain":"example.com"}'
npx @reneturcios/sitedoctor free_page_check '{"url":"https://example.com"}'
npx @reneturcios/sitedoctor --version

終了コード：成功時は 0、isError の結果の場合は 1、 使用方法のエラーの場合は 2 です。

MCP サーバー

npx -y @reneturcios/sitedoctor mcp

MCP クライアントの設定：

{
  "mcpServers": {
    "sitedoctor": {
      "command": "npx",
      "args": ["-y", "@reneturcios/sitedoctor", "mcp"]
    }
  }
}

Docker

docker run -i ghcr.io/cloudcorprecords/sitedoctor
docker run --rm ghcr.io/cloudcorprecords/sitedoctor --version

コンテナのデフォルトコマンドは mcp です。そのため、最初の形式は stdio MCP サーバーとして動作し、それ以外の引数は通常どおり CLI に 渡されます。

開発

npm install
npm run build
npm test
npm run dev

テストスイートは、スタブ化した JSON-RPC 上流だけを使用して実行されます。 実際のネットワーク呼び出しはありません。

ライセンス

MIT — LICENSE を参照してください。