Back to Discover

mcp-uptime-kuma

connector

DavidFuchs

A Model Context Protocol (MCP) server for Uptime Kuma version 2.

View on GitHub
0 starsSynced Aug 2, 2026

Install to Claude Code

/plugin marketplace add DavidFuchs/mcp-uptime-kuma

README

mcp-uptime-kuma

A Model Context Protocol (MCP) server for Uptime Kuma version 2. Supports stdio and streamable HTTP transports.

GitHub Stars GitHub Last Commit GitHub Repo Size

GitHub Actions - npmjs npmjs Version npmjs Downloads

GitHub Actions - DockerHub Docker Version Docker Pulls

Features

  • Real-time Monitoring: Access monitors, heartbeats, uptime, and responsiveness metrics via Socket.IO with instant status change notifications.
  • Context-Friendly: Returns only essential data by default to avoid overwhelming LLM context windows.
  • Multiple Transports: Supports stdio (local) and streamable HTTP (remote) transports.

Quick Start

Using npx (stdio transport)

Add this to your MCP client configuration:

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

Using Docker (streamable HTTP transport)

Option 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

Option 2: Docker Compose

A docker-compose.yml file is provided in the repository. Download it, configure your environment variables, and run:

docker compose up -d

Then configure your MCP client to connect to the endpoint:

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

See Authentication Methods for JWT token and anonymous authentication options.

Example Conversation

MCP server answering questions about Uptime Kuma monitors Conversation in LibreChat where the mcp-uptime-kuma server is providing real-time information from Uptime Kuma.

Available Tools

Monitors

ToolPurpose
getMonitorSummaryGet a quick overview of all monitors with their current status. Supports filtering.
listMonitorsGet the full list of all monitors with configurations. Supports filtering.
listMonitorTypesGet all available monitor types supported by Uptime Kuma.
getMonitorGet detailed configuration for a specific monitor by ID.
createMonitorCreate a new monitor (requires name and type at minimum).
updateMonitorUpdate an existing monitor's configuration.
deleteMonitorPermanently delete a monitor and all its heartbeat history.
pauseMonitorPause a monitor to stop performing checks.
resumeMonitorResume a paused monitor to restart checks.

Heartbeats

ToolPurpose
listHeartbeatsGet status check history for all monitors.
getHeartbeatsGet status check history for a specific monitor.

Notifications

ToolPurpose
listNotificationsList all configured notification channels (Slack, Discord, email, webhooks, etc.).
addNotificationCreate a new notification channel.
updateNotificationUpdate an existing notification channel.
deleteNotificationPermanently delete a notification channel.

Tags

ToolPurpose
listTagsList all tags defined in Uptime Kuma.
addTagCreate a new tag that can be assigned to monitors.
deleteTagPermanently delete a tag (removes it from all monitors).

Maintenance

ToolPurpose
getMaintenanceWindowsList all scheduled maintenance windows.
createMaintenanceSchedule a new maintenance window.

Status Pages & Settings

ToolPurpose
listStatusPagesList all configured status pages.
getSettingsGet Uptime Kuma server settings.

Filtering

getMonitorSummary and listMonitors support filtering by:

  • keywords: Space-separated keywords for fuzzy matching against monitor pathNames
  • type: Monitor type(s), comma-separated (e.g., "http", "http,ping,dns")
  • active: Filter by active (true) or inactive (false) monitors
  • maintenance: Filter by maintenance mode status
  • tags: Tag name and optional value, comma-separated (e.g., "production", "env=staging")
  • status (getMonitorSummary only): Heartbeat status ("0"=DOWN, "1"=UP, "2"=PENDING, "3"=MAINTENANCE)

Examples:

getMonitorSummary({ status: "0" })                    // All DOWN monitors
getMonitorSummary({ type: "http", maintenance: true }) // HTTP monitors in maintenance
listMonitors({ tags: "production,region=us-east" })    // Monitors with specific tags

Authentication Methods

Anonymous Authentication

If authentication is disabled on your Uptime Kuma instance, only UPTIME_KUMA_URL is required.

Username/Password Authentication

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 Token Authentication

Recommended for 2FA users. Takes precedence over username/password if both are provided.

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

Obtaining Your JWT Token

Using the CLI utility (recommended):

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

Using Docker:

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

From browser: Open Developer Tools → Storage/Application → Local Storage → find token key.

Credential Redaction

Read tools return *** in place of secrets rather than the values themselves.

Uptime Kuma's socket API returns configuration verbatim — its web UI masks credentials at render time. That is fine for a browser and not fine for an MCP server, whose output lands in an LLM's context window and is then persisted in conversation transcripts, logs and synced history. Asking "what am I monitoring?" should not write a live SMTP password or a third-party API key into storage you may not control.

What is withheld:

ToolWithheld
listNotificationseverything in config except type/name/isDefault/applyExisting. The withheld field names are listed in redactedConfigKeys
listMonitors, getMonitorpushToken, basic_auth_pass, bearer_token, oauth_client_secret, radiusPassword, radiusSecret, mqttPassword, rabbitmqPassword, tlsCert/tlsKey/tlsCa, databaseConnectionString, headers, grpcMetadata, plus anything matching `/pass
listDockerHostsuser:password@ inside a dockerDaemon URL
getHeartbeats, listHeartbeatsany column Uptime Kuma returns beyond the declared heartbeat fields (e.g. response, which can carry a service's response body) is dropped, and user:password@ inside a URL quoted in the status message is scrubbed
getSettingsany secret-named field Uptime Kuma returns (e.g. steamAPIKey)
getMonitorSummarynothing — it returns no credentials to begin with

hostname, port, url, authMethod, oauth_token_url, oauth_scopes and usernames stay visible: hiding useful configuration is how a redaction feature gets switched off.

To get the real values, either pass includeSecrets: true on the call:

listNotifications({ includeSecrets: true })

or enable it globally:

UPTIME_KUMA_INCLUDE_SECRETS=true

The per-call parameter wins over the environment variable in both directions, so a permissive deployment can still ask one call to redact.

Writing *** back is safe. updateMonitor and updateNotification restore the stored value when a field arrives as the marker, and report which fields they preserved. This matters most for updateNotification: Uptime Kuma replaces the notification row rather than merging it, so without this a read-edit-write round trip would replace a working password with three asterisks. If there is no stored value to restore, the call fails rather than writing a credential that looks set and cannot work.

updateDockerHost gets the same protection for the credentials embedded in a dockerDaemon URL: a http://***:***@host:2375 read back from listDockerHosts has its userinfo restored from the stored URL rather than persisted verbatim, so repointing a host without re-entering its credentials does not wipe them.

The MCP logging channel gets the same rule. The debug log for a live heartbeat reports the monitored service's status message by length only (msgLength=...), never its content, since that message can echo a target URL with an embedded user:password@ or a slice of a response body, and on the stdio transport those log notifications reach the client.

LibreChat Configuration

stdio transport:

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

streamable HTTP transport:

Update the allowed domains to whatever domain you're using in the URL (e.g., localhost or host.docker.internal for Docker setups):

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

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

Contributing

For development setup, building, testing, and project structure, see CONTRIBUTING.md.

Learn More

Security

To report a vulnerability, please see SECURITY.md.

Disclaimer

This is a personal, free, open-source side project provided "as is" under the MIT License, without warranty of any kind. You install and run it yourself, and it connects to an Uptime Kuma instance that you control. The author is not responsible for any damage, data loss, downtime, or other consequences arising from its use. Use at your own risk.

License

Licensed under the MIT License.

Rendered live from DavidFuchs/mcp-uptime-kuma's GitHub README — not stored, always reflects the source repo.

1 Install Method

NameDescriptionCategorySource
npm packageInstall via npm (stdio transport)mcp-server@davidfuchs/mcp-uptime-kuma

0 Comments

Login required
Log in to post a comment or update on this repo.

No comments yet — be the first to share an update.