mcp-uptime-kuma

mcp-uptime-kuma

Uptime Kuma バージョン 2 用の Model Context Protocol (MCP) サーバーです。stdio とストリーム可能な HTTP トランスポートをサポートしています。

機能

• リアルタイム監視：Socket.IO 経由でモニター、ハートビート、稼働時間、応答性のメトリクスにアクセスし、ステータス変更の通知を即座に受け取れます。
• コンテキストに配慮：LLM のコンテキストウィンドウが過剰な情報でいっぱいにならないよう、デフォルトでは必要なデータのみを返します。
• 複数のトランスポート：stdio（ローカル）とストリーム可能な HTTP（リモート）トランスポートをサポートしています。

クイックスタート

npx を使用（stdio トランスポート）

MCP クライアントの設定に以下を追加します。

{
  "mcpServers": {
    "uptime-kuma": {
      "command": "npx",
      "args": ["-y", "@davidfuchs/mcp-uptime-kuma@latest"],
      "env": {
        "UPTIME_KUMA_URL": "http://your-uptime-kuma-instance:3001",
        "UPTIME_KUMA_USERNAME": "your_username",
        "UPTIME_KUMA_PASSWORD": "your_password"
      }
    }
  }
}

@latest サフィックスはそのままにしてください。これがない場合、npx は初回実行時にキャッシュしたバージョンを再利用し、新しいリリースを取得しません。

Docker を使用（ストリーム可能な HTTP トランスポート）

オプション 1：Docker Run

docker run -d \
  --name mcp-uptime-kuma \
  -p 3000:3000 \
  -e UPTIME_KUMA_URL=http://your-uptime-kuma-instance:3001 \
  -e UPTIME_KUMA_USERNAME=your_username \
  -e UPTIME_KUMA_PASSWORD=your_password \
  davidfuchs/mcp-uptime-kuma:latest \
  -t streamable-http

オプション 2：Docker Compose

リポジトリには docker-compose.yml ファイルが用意されています。ダウンロードして環境変数を設定し、次を実行します。

docker compose up -d

次に、エンドポイントに接続するよう MCP クライアントを設定します。

{
  "mcpServers": {
    "uptime-kuma": {
      "url": "http://localhost:3000/mcp"
    }
  }
}

JWT トークン認証と匿名認証のオプションについては、認証方法を参照してください。

上記のエンドポイントには認証がありません。 ポート 3000 に接続できる人は誰でも、Uptime Kuma インスタンスを完全に 読み書きできます。localhost の外部に公開する前に、 HTTP エンドポイントの保護を参照してください。

会話例

LibreChat での会話例。mcp-uptime-kuma サーバーが Uptime Kuma からリアルタイムの情報を提供しています。

利用可能なツール

モニター

ツール	目的
getMonitorSummary	現在のステータスとともに、すべてのモニターの概要をすばやく取得します。フィルタリングに対応しています。
listMonitors	設定を含む、すべてのモニターの一覧を取得します。フィルタリングに対応しています。
listMonitorTypes	Uptime Kuma がサポートする、利用可能なすべてのモニタータイプを取得します。
getMonitor	ID を指定して、特定のモニターの詳細な設定を取得します。
createMonitor	新しいモニターを作成します（最低限、名前とタイプが必要です）。
updateMonitor	既存のモニターの設定を更新します。
deleteMonitor	モニターとそのすべてのハートビート履歴を完全に削除します。
pauseMonitor	モニターを一時停止し、チェックを停止します。
resumeMonitor	一時停止中のモニターを再開し、チェックを再開します。

ハートビート

ツール	目的
listHeartbeats	すべてのモニターのステータスチェック履歴を取得します。
getHeartbeats	特定のモニターのステータスチェック履歴を取得します。

通知

ツール	用途
listNotifications	設定済みのすべての通知チャネル（Slack、Discord、メール、Webhook など）を一覧表示します。
addNotification	新しい通知チャネルを作成します。
updateNotification	既存の通知チャネルを更新します。
deleteNotification	通知チャネルを完全に削除します。

タグ

ツール	用途
listTags	Uptime Kuma で定義されているすべてのタグを一覧表示します。
addTag	モニターに割り当て可能な新しいタグを作成します。
deleteTag	タグを完全に削除します（すべてのモニターから削除されます）。

メンテナンス

ツール	用途
getMaintenanceWindows	各メンテナンスウィンドウの対象モニターとともに、すべてのメンテナンスウィンドウを一覧表示します。
createMaintenance	新しいメンテナンスウィンドウをスケジュールし、対象となるモニターを設定します。
updateMaintenance	メンテナンスウィンドウのスケジュール、詳細、またはモニター一覧を変更します。
pauseMaintenance	メンテナンスウィンドウをオフにします（手動ウィンドウを終了します）。
resumeMaintenance	一時停止中のメンテナンスウィンドウを再びオンにします（手動ウィンドウを開始します）。
deleteMaintenance	メンテナンスウィンドウを完全に削除します。

ステータスページと設定

ツール	用途
listStatusPages	設定済みのすべてのステータスページを一覧表示します。
getSettings	Uptime Kuma サーバーの設定を取得します。

フィルタリング

getMonitorSummary と listMonitors では、次の条件でフィルタリングできます。

• keywords：モニターの pathNames とあいまい一致させる、スペース区切りのキーワード
• type：モニターの種類。カンマ区切りで指定します（例："http"、"http,ping,dns"）
• active：アクティブ（true）または非アクティブ（false）のモニターでフィルタリングします
• maintenance：メンテナンスモードの状態でフィルタリングします
• tags：タグ名と任意の値をカンマ区切りで指定します（例："production"、"env=staging"）
• parentId：グループのモニター ID を指定し、そのグループの直接の子を返します。親を持たないトップレベルのモニターを指定する場合は null を渡します。再帰的な検索ではありません。さらに深い階層をたどるには、各子グループの childrenIDs を使用します。
• status（getMonitorSummary のみ）：ハートビートの状態（"0"＝DOWN、"1"＝UP、"2"＝PENDING、"3"＝MAINTENANCE）

例：

getMonitorSummary({ status: "0" })                     // All DOWN monitors
getMonitorSummary({ type: "http", maintenance: true }) // HTTP monitors in maintenance
getMonitorSummary({ parentId: 12, status: "0" })       // What's down inside group 12
listMonitors({ tags: "production,region=us-east" })    // Monitors with specific tags
listMonitors({ parentId: 12 })                         // Direct children of group 12
listMonitors({ parentId: null })                       // Top-level monitors only

認証方法

匿名認証

Uptime Kuma インスタンスで認証が無効になっている場合、必要なのは UPTIME_KUMA_URL のみです。

ユーザー名／パスワード認証

UPTIME_KUMA_URL=http://your-instance:3001
UPTIME_KUMA_USERNAME=your_username
UPTIME_KUMA_PASSWORD=your_password
UPTIME_KUMA_2FA_TOKEN=123456  # Optional, only if 2FA is enabled

JWT トークン認証

2FA を使用するユーザーにおすすめです。両方が指定されている場合、ユーザー名／パスワードより優先されます。

UPTIME_KUMA_URL=http://your-instance:3001
UPTIME_KUMA_JWT_TOKEN=your_jwt_token

JWT トークンの取得方法

CLI ユーティリティを使用する方法（推奨）：

npx -p @davidfuchs/mcp-uptime-kuma@latest mcp-uptime-kuma-get-jwt http://localhost:3001 admin mypassword

Docker を使用する方法：

docker run --rm davidfuchs/mcp-uptime-kuma:latest get-jwt http://host.docker.internal:3001 admin mypassword

ブラウザーから取得する方法： 開発者ツール → ストレージ／アプリケーション → ローカルストレージを開き、token キーを探します。

認証プロキシの背後で使用する場合（Cloudflare Access など）

Uptime Kuma が、独自の認証情報を要求するプロキシ（Cloudflare Zero Trust Access アプリケーション、oauth2-proxy、API ゲートウェイなど）の背後にある場合は、UPTIME_KUMA_HEADERS に、各リクエストで送信するヘッダーを格納した JSON オブジェクトを設定します。この設定は上記のいずれの方法とも併用できます。これらの方法は引き続き、Uptime Kuma 自体へのログインに使用されます。

Cloudflare Access の場合は、サービス トークンを作成し、それを許可する Service Auth ポリシーをアプリケーションに追加してから、次のようにします。

UPTIME_KUMA_URL=https://uptime.example.com
UPTIME_KUMA_HEADERS={"CF-Access-Client-Id":"<client-id>.access","CF-Access-Client-Secret":"<client-secret>"}
UPTIME_KUMA_USERNAME=your_username
UPTIME_KUMA_PASSWORD=your_password

MCP クライアントの JSON 設定では値が文字列になるため、内部の引用符をエスケープする必要があります。

"UPTIME_KUMA_HEADERS": "{\"CF-Access-Client-Id\":\"<client-id>.access\",\"CF-Access-Client-Secret\":\"<client-secret>\"}"

mcp-uptime-kuma-get-jwt も同じ変数を読み取ります。不正な形式の値がある場合、問題のヘッダー名を示すエラーとともにサーバーの起動が停止します。ヘッダーの値がログに記録されることはありません。

HTTP エンドポイントの保護

-t streamable-http の場合にのみ適用されます。stdio トランスポートには保護すべきリスナーがなく、MCP 仕様の規定どおり、認証情報は環境から取得します。

/mcp にアクセスできる人は誰でも、モニターの削除を含め、Uptime Kuma インスタンスに対する完全な読み書き権限を持ちます。これを保護する設定は 2 つあり、既存のデプロイをアップグレードで壊さないよう、どちらもデフォルトでは制限が緩く設定されています。この状態では、サーバーの起動時に警告が表示されます。

変数	デフォルト	目的
MCP_AUTH_TOKEN	未設定（認証なし）	呼び出し元が Authorization: Bearer <token> として提示する必要がある共有シークレットです。それ以外の場合は 401 が返されます。
ALLOWED_ORIGIN	*（検証なし）	/mcp への呼び出しを許可するブラウザーのオリジンをカンマ区切りで指定します。Origin が一覧にないリクエストには 403 が返されます。Origin ヘッダーのないリクエスト（すべてのネイティブ MCP クライアント）は常に許可されます。
HOST	0.0.0.0	バインドするアドレスです。コンテナー外でローカル実行する場合は 127.0.0.1 に設定してください。
PORT	3000	リッスンするポートです。
TRUST_PROXY	未設定（信頼なし）	サーバーの前段にあるリバースプロキシからの X-Forwarded-For を信頼し、レート制限でプロキシではなく実際のクライアント IP を使用します。ホップ数（1）、true／false、または IP／サブネットのリストを指定できます。Express の trust proxy ドキュメント を参照してください。

/health は意図的に認証なしのままにしてあるため、コンテナーのヘルスチェックやロードバランサーのプローブは引き続き動作します。ここで報告されるのは稼働状態のみです。

トークンの設定

高エントロピーのシークレットを生成してください。これはパスワードであり、一定時間の比較が行われるため、保護の強さを決めるのは長さだけです。

openssl rand -base64 32

docker run -d \
  --name mcp-uptime-kuma \
  -p 3000:3000 \
  -e UPTIME_KUMA_URL=http://your-uptime-kuma-instance:3001 \
  -e UPTIME_KUMA_JWT_TOKEN=your_jwt_token \
  -e MCP_AUTH_TOKEN=your_generated_secret \
  davidfuchs/mcp-uptime-kuma:latest \
  -t streamable-http

クライアントはヘッダーとして送信します。

{
  "mcpServers": {
    "uptime-kuma": {
      "url": "http://localhost:3000/mcp",
      "headers": {
        "Authorization": "Bearer your_generated_secret"
      }
    }
  }
}

Origin の検証が別途必要な理由

共有シークレットは、それを提示できない人を遮断します。しかし、ブラウザーがすでに信頼しているウェブサイトは遮断できません。DNS リバインディング攻撃では、evil.example 上のページが自身のホスト名を 127.0.0.1 に解決するため、ブラウザーはローカルサーバーへのリクエストを同一オリジンとして扱います。そのため、プリフライトは行われず、CORS も適用されません。サーバーが受信した Origin ヘッダーを、想定されるオリジンの一覧と照合することだけが有効なチェックとして残ります。このため、MCP 仕様では SHOULD ではなく MUST と定められています。

ネイティブクライアントしか使用しない場合、ALLOWED_ORIGIN を未設定のままにしても影響はありません。これらのクライアントは Origin ヘッダーを送信しません。ブラウザーベースのクライアントを使用する場合は、そのオリジンを一覧に追加してください。

ALLOWED_ORIGIN=https://librechat.example.com,http://localhost:5173

リバースプロキシの背後での実行

TRUST_PROXY を設定しない場合、Express にはすべてのリクエストがプロキシの IP から来たように見えるため、レート制限はすべてのクライアントに共有の 100 リクエスト枠を適用します。その結果、いずれかのクライアントのトラフィックが合計で上限に達すると、誤った 429 が返されるようになります。

TRUST_PROXY にサーバー前段のプロキシホップ数を設定すると、X-Forwarded-For から実際のクライアント IP を読み取れるようになります。

TRUST_PROXY=1

このヘッダーを削除して再設定する、管理下のプロキシが実際に存在する場合にのみ設定してください。サーバーに直接アクセスできる場合や、プロキシが受け取った X-Forwarded-For をそのまま通過させる場合、クライアントはこのヘッダーを偽装してリクエストごとに新しいレート制限枠を取得でき、レート制限が完全に無効になります。

認証情報の秘匿

読み取りツールは、秘密情報を実際の値の代わりに *** で返します。

Uptime Kuma のソケット API は設定をそのまま返します。Web UI は描画時に認証情報をマスクします。ブラウザーでは問題ありませんが、出力が LLM のコンテキストウィンドウに入り、その後、会話のトランスクリプト、ログ、同期された履歴に保存される MCP サーバーでは問題です。「何を監視していますか？」と尋ねた結果、管理できるとは限らないストレージに有効な SMTP パスワードやサードパーティー API キーが書き込まれてはいけません。

秘匿される情報：

ツール	秘匿される情報
listNotifications	config 内の type／name／isDefault／applyExisting 以外のすべて。秘匿されたフィールド名は redactedConfigKeys に一覧表示されます
listMonitors、getMonitor	pushToken、basic_auth_pass、bearer_token、oauth_client_secret、radiusPassword、radiusSecret、mqttPassword、rabbitmqPassword、tlsCert／tlsKey／tlsCa、databaseConnectionString、headers、grpcMetadata に加え、`/pass
listDockerHosts	dockerDaemon URL 内の user:password@
getHeartbeats、listHeartbeats	Uptime Kuma が返す、宣言済みのハートビートフィールド以外の列（例：サービスのレスポンス本文を含む可能性のある response）はすべて破棄されます。また、ステータスメッセージ内に引用された URL の user:password@ はスクラブされます
getSettings	Uptime Kuma が返す、秘密情報を示す名前のフィールド（例：steamAPIKey）
getMonitorSummary	なし。そもそも認証情報を返しません

hostname、port、url、authMethod、oauth_token_url、oauth_scopes、ユーザー名は表示されたままです。有用な設定まで隠してしまうと、秘匿機能が無効にされてしまうためです。

実際の値を取得するには、呼び出し時に includeSecrets: true を渡すか、

listNotifications({ includeSecrets: true })

または、グローバルに有効にします。

UPTIME_KUMA_INCLUDE_SECRETS=true

どちらの場合も、呼び出しごとのパラメーターは環境変数より優先されます。そのため、設定が許容的なデプロイ環境でも、特定の呼び出しでは秘匿を有効にできます。

*** を書き戻しても安全です。 updateMonitor と updateNotification は、フィールドにマーカーが指定されている場合、保存済みの値を復元し、保持したフィールドを報告します。これは特に updateNotification で重要です。Uptime Kuma は通知行をマージせず置き換えるため、この処理がなければ、読み取り・編集・書き戻しの一連の処理で、動作中のパスワードが 3 つのアスタリスクに置き換わってしまいます。復元する保存済みの値がない場合、設定済みに見えても動作しない認証情報を書き込むのではなく、呼び出しは失敗します。

updateDockerHost にも、dockerDaemon URL に含まれる認証情報に対する同じ保護が適用されます。listDockerHosts から読み取った http://***:***@host:2375 は、そのまま保存されず、保存済み URL からユーザー情報が復元されます。そのため、認証情報を再入力せずにホストの接続先を変更しても、認証情報が消えることはありません。

MCP のログ出力チャネルにも同じルールが適用されます。稼働中のハートビートに関するデバッグログには、監視対象サービスのステータスメッセージの内容ではなく、長さのみ（msgLength=...）が記録されます。メッセージには、user:password@ を含むターゲット URL やレスポンス本文の一部が含まれる可能性があり、stdio トランスポートでは、これらのログ通知がクライアントに届くためです。

LibreChat の設定

stdio トランスポート：

mcpServers:
  uptime-kuma:
    command: npx
    args: ["-y", "@davidfuchs/mcp-uptime-kuma@latest"]
    env:
      UPTIME_KUMA_URL: "http://your-instance:3001"
      UPTIME_KUMA_USERNAME: "your_username"
      UPTIME_KUMA_PASSWORD: "your_password"
    serverInstructions: true

ストリーム可能な HTTP トランスポート：

URL で使用するドメインに合わせて、許可するドメインを更新してください（例：Docker のセットアップでは localhost または host.docker.internal）。

mcpServers:
  uptime-kuma:
    type: streamable-http
    url: "http://mcp-uptime-kuma:3000/mcp"
    serverInstructions: true

mcpSettings:
  allowedDomains:
    - 'mcp-uptime-kuma'

貢献

開発環境のセットアップ、ビルド、テスト、プロジェクト構成については、CONTRIBUTING.md を参照してください。

さらに詳しく

• Uptime Kuma
• Model Context Protocol のドキュメント
• MCP TypeScript SDK
• MCP 仕様

セキュリティ

脆弱性を報告するには、SECURITY.md を参照してください。

免責事項

これは個人による無料のオープンソースのサイドプロジェクトであり、いかなる保証もなく「現状有姿」で MIT License のもと提供されています。ご自身でインストールして実行し、ご自身が管理する Uptime Kuma インスタンスに接続します。 本プロジェクトの作者は、使用に起因するいかなる損害、データ損失、ダウンタイム、その他の結果についても責任を負いません。ご自身の責任でご使用ください。

ライセンス

MIT License のもとでライセンスされています。