mcpField
D
Domain Liveness

Domain Liveness

リモート
github.com/modelcontextprotocolクラウド・インフラ7.4k1 日前に更新
リポジトリ

Domain Liveness について

Domain Liveness は、企業サイトが現在も稼働しているかを確認する MCP サーバーです。DNS と HTTP を別々に検査し、apex ドメインと www サブドメインの両方を対象とします。

主な機能

  1. 01apex ドメインと www サブドメインを確認
  2. 02DNS と HTTP を個別に検査

活用シーン

  1. 01取引先サイトが稼働中か確認
  2. 02企業ドメインの DNS や HTTP アクセスを切り分け

MCP 対応

本プロジェクトは MCP サーバーであり、サイトの稼働状況チェックを MCP クライアントに提供します。

設定

リモートサーバーはインストール不要です。クライアントを選んで設定をコピーするか、ワンクリックで導入できます。

エンドポイントhttps://domain-liveness-mcp.ottobot2025.workers.dev/mcp
インストールコマンドをコピー
Claude CodeTerminal
Cursor.cursor/mcp.json
VS Code.vscode/mcp.json
Claude Desktopclaude_desktop_config.json
Windsurf~/.codeium/windsurf/mcp_config.json

コマンドはターミナルで実行し、JSON は各クライアントの MCP 設定に貼り付けて再起動します。認可が必要なサーバーは初回接続時にログインを求めます。

ツール

1
パラメーター型必須説明
domainstringはいホスト名または URL。例:example.com または https://www.example.com

詳細

MCP レジストリ

MCP レジストリは、MCP サーバーのアプリストアのように、MCP クライアントに MCP サーバーの一覧を提供します。

📤 MCP サーバーを公開する | ⚡️ ライブ API ドキュメント | 👀 エコシステムのビジョン | 📖 ドキュメント全文

開発状況

2025-10-24 更新:レジストリ API は API の凍結(v0.1) に入りました 🎉。今後 1 か月以上にわたり、API は破壊的変更のない安定した状態を保つため、インテグレーターは安心してサポートを実装できます。この凍結は v0.1 に適用され、v0 の開発は引き続き進行します。この期間を利用して、実際の統合で API を検証し、一般提供に向けた v1 の策定に役立つフィードバックを集めます。貢献とご辛抱をいただいた皆さんに感謝します。皆さんの参加が、ここまでたどり着くうえで重要な役割を果たしました!

2025-09-08 更新:レジストリのプレビュー版が公開されました 🎉(発表ブログ記事)。システムはより安定しましたが、まだプレビューリリースのため、破壊的変更やデータのリセットが発生する可能性があります。その後、一般提供(GA)リリースを予定しています。GitHub のディスカッションまたは #registry-dev Discord(参加方法はこちら)で、ぜひフィードバックをお寄せください。

レジストリ作業部会:

貢献

複数のチャンネルで協力しています。詳しくはmodelcontextprotocol.io/community/communicationをご覧ください。

多くの場合(常にではありませんが)、アイデアは次の流れで進みます。

クイックスタート:
前提条件
  • Docker
  • Go - バージョンはgo.modのgoディレクティブに準拠します。Go ツールチェーンが自動的に取得します
  • ko - Go 用コンテナイメージビルダー(インストール手順)
  • golangci-lint - バージョンはci.ymlのgolangci-lint-actionの固定バージョンに準拠します。ローカルの lint 結果が CI と一致します
サーバーの実行
# Start full development environment
make dev-compose

これにより、PostgreSQL を使用して localhost:8080 でレジストリが起動します。データベースには一時ストレージが使用され、コンテナを再起動するたびにリセットされるため、開発やテストでクリーンな状態を保てます。

注: レジストリでは、コンテナイメージのビルドに ko を使用します。make dev-compose コマンドは、サービスの起動前に ko でレジストリイメージを自動的にビルドし、ローカルの Docker デーモンに読み込みます。

デフォルトでは、起動を速くするため、フィルタリングされたサーバーのサブセットを本番 API からシードします。これにより、ローカル環境が本番環境の動作を再現し、すべてのシードデータが検証を通過します。オフラインで開発する場合は、MCP_REGISTRY_SEED_FROM=data/seed.json MCP_REGISTRY_ENABLE_REGISTRY_VALIDATION=false make dev-compose を使用すると、検証せずにファイルからシードできます。

環境変数を使用して、docker-compose.yml でセットアップを構成できます。参考情報は .env.example をご覧ください。

代替方法:ビルド済み Docker イメージの実行

ビルド済みの Docker イメージは、GitHub Container Registry に自動的に公開されます。このイメージには PostgreSQL が含まれていないため、独自の PostgreSQL を実行し、MCP_REGISTRY_DATABASE_URL を使ってレジストリに接続する必要があります(動作する例については docker-compose.yml をご覧ください)。

# Run latest stable release
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:latest

# Run latest from main branch (continuous deployment)
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:main

# Run specific release version
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:v1.0.0

# Run development build from main branch
docker run -p 8080:8080 ghcr.io/modelcontextprotocol/registry:main-20250906-abc123d

利用可能なタグ:

  • リリース:latest、v1.0.0、v1.1.0 など
  • 継続ビルド:main(main ブランチの最新ビルド)
  • 開発用:main-<date>-<sha>(特定のコミットのビルド)
サーバーの公開

MCP サーバーの公開は、このリポジトリへのプルリクエストでは行いません。server.json、サーバーディレクトリ、または data/seed.json のエントリーを追加しても、プルリクエストがマージされた場合を含め、サーバーは公開も一覧への掲載もされません。サーバー自身のプロジェクトで mcp-publisher CLI を使用してください。

サーバーを公開するため、シンプルな CLI を用意しました。次のように使用できます。

# Build the latest CLI
make publisher

# Use it!
./bin/mcp-publisher --help

詳しくは、パブリッシャーガイドをご覧ください。

その他のコマンド
# Run lint, schema validation, and all tests
# Note: this also runs `make dev-down`, stopping any running dev-compose environment
make check

開発に役立つコマンドがほかにもいくつかあります。make help を実行して詳細を確認するか、Makefile をご覧ください。

アーキテクチャ

プロジェクト構成
├── cmd/                     # Application entry points
│   ├── publisher/           # Server publishing tool
│   └── registry/            # Registry API server
├── data/                    # Seed data
├── deploy/                  # Deployment configuration (Pulumi)
├── docs/                    # Documentation
├── internal/                # Private application code
│   ├── api/                 # HTTP handlers and routing
│   ├── auth/                # Authentication (GitHub OAuth, JWT, namespace blocking)
│   ├── config/              # Configuration management
│   ├── database/            # Data persistence (PostgreSQL)
│   ├── importer/            # Seed data import
│   ├── service/             # Business logic
│   ├── telemetry/           # Metrics and monitoring
│   └── validators/          # Input validation
├── pkg/                     # Public packages
│   ├── api/                 # API types and structures
│   │   └── v0/              # Version 0 API types
│   └── model/               # Data models for server.json
├── scripts/                 # Development and testing scripts
├── tests/                   # Integration tests
└── tools/                   # CLI tools and utilities
    └── validate-*.sh        # Schema validation tools
認証

公開では、複数の認証方法をサポートしています。

  • GitHub OAuth - GitHub にログインして公開する場合
  • GitHub OIDC - GitHub Actions から公開する場合
  • DNS 検証 - ドメインとそのサブドメインの所有権を証明する場合
  • HTTP 検証 - ドメインの所有権を証明する場合

レジストリは公開時に名前空間の所有権を検証します。たとえば、次のように公開する場合は:

  • io.github.domdomegg/my-cool-mcp を公開するには、GitHub に domdomegg としてログインするか、domdomegg のリポジトリにある GitHub Action から実行する必要があります
  • me.adamjones/my-cool-mcp を公開するには、DNS または HTTP のチャレンジを通じて adamjones.me の所有権を証明する必要があります

コミュニティプロジェクト

コミュニティが作成した注目すべきレジストリ関連の取り組みについては、コミュニティプロジェクトをご覧ください。

その他のドキュメント

ここで質問の答えが見つからない場合は、詳しくはドキュメントをご覧ください。

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。