Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/mcp-uptime-kuma/issues.md or /mcp/mcp-uptime-kuma/issues.json, or Pod over MCP.

Reported issues for mcp-uptime-kuma

Pod holds 17 of 22 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to mcp-uptime-kuma.

Most discussed

Failed to authenticate with Uptime Kuma: Error: Login failed

Hi David,

I'm trying to use this with LibreChat and used your example in the yaml file.

I'm getting authentication error (see below).

I'm fairly sure all my credentials are correct and I also tried using an API Key. I have MFA turned on so could this causing the error?

2025-11-22 20:50:21 error: [MCP][User: 69220b7f392bc8f5fc74ec2a][uptime-kuma] Connection failed: MCP error -32000: Connection closed
Failed to authenticate with Uptime Kuma: Error: Login failed
    at Socket.<anonymous> (f

[Read the thread](https://github.com/DavidFuchs/mcp-uptime-kuma/issues/3) · 2025-11-22 · closed · external user · 6 comments

### Error converting schema Invalid schema (in Home Assistant to Komodo MCP docker instance)

In my Home Assistant, I see this error now (this has worked previously, so a recent update broke it)

Failed setup, will retry: Error converting schema Invalid schema, missing type: {'type': 'object', 'properties': {'name': {'type': 'string', 'description': 'Human-readable name for this notification channel'}, 'type': {'type': 'string', 'description': 'Notification type (e.g. slack, ntfy, discord, telegram, webhook, smtp)'}, 'isDefault': {'type': 'boolean', 'description': 'Enable by default

Read the thread · 2026-07-15 · open · external user · 3 comments

[Feature Request] Add Authentication to MCP

Right now mcp-uptime-kuma has no protection itself.

Please allow to specify a token as environment variable.

When the token is set it must be passed as Bearer token on any request, if it's incorrect it should return 401.

Read the thread · 2026-07-26 · closed · external user · 2 comments

listNotifications returns notification credentials in plaintext (SMTP passwords, ntfy passwords, tokens)

Summary

listNotifications returns each channel's full config blob verbatim, including its secrets. For an SMTP channel that means smtpUsername and smtpPassword; for ntfy, ntfypassword; and by inspection the same applies to any type storing a token or webhook URL.

This isn't a Kuma bug — Kuma's socket API returns the config as-is, and the web UI masks it at render time. It matters more here because an MCP server's output lands in an LLM's context window and is persisted in client-s

Read the thread · 2026-07-22 · closed · outside contributor · 2 comments

createMonitor / updateMonitor silently drop description — field missing from inputSchema

Summary

createMonitor and updateMonitor accept a description argument without complaint and return success, but the value is never written. getMonitor returns description: null afterwards and the Kuma database column stays NULL.

Same class as the already-fixed #41 (tags), #42 (docker_container / docker_host) and #50 (dns_resolve_server / dns_resolve_type): the field simply isn't declared in the tool's inputSchema, so the MCP SDK strips it before it reaches the Kuma client.

Ve

Read the thread · 2026-07-22 · closed · external user · 2 comments

outputSchema declares JSON Schema draft-07 — every tool call fails in Claude Desktop (2020-12-only validator)

Summary

Every tool exposed by this server is unusable in Claude Desktop (and any other MCP client whose structured-output validator is Ajv 2020-12 only). Each tools/call is rejected client-side, before it reaches the server, because the outputSchema declares the draft-07 dialect.

Client error message (verbatim, identical for all 31 tools):

Tool 'uptime-kuma-getmonitorsummary' has an invalid outputSchema:
JSON Schema declares an unsupported dialect ("$schema": "http://json-schem

[Read the thread](https://github.com/DavidFuchs/mcp-uptime-kuma/issues/83) · 2026-08-14 · closed · external user · 1 comment

### --build-arg VERSION has no effect on the built image

`docker build --build-arg VERSION=x.y.z` does not reach the final
image. `ARG`/`LABEL` are declared only in the builder stage, and
`src/version.ts` keeps its `0.0.0-dev` placeholder ("replaced by
CI/CD"), so the running server reports `0.0.0-dev` regardless of what
was passed in.

Effect: a locally built image cannot report which version it was built
from — the tag is the only carrier. Not a problem for images published
by CI, but it makes the documented build argument misleading for
anyone buil

[Read the thread](https://github.com/DavidFuchs/mcp-uptime-kuma/issues/68) · 2026-07-29 · closed · outside contributor · 1 comment

### Preferred channel for a private security report?

Hi — thanks for maintaining this server. We run it in production (behind a read-only gate), and I sent #48 a while back.

While auditing our deployment I ran into a security-relevant issue that I'd rather not describe in a public issue: a useful description would double as a reproduction guide, and it affects every deployment rather than just our setup.

There's no SECURITY.md here and private vulnerability reporting appears to be turned off, so there's no obvious private channel. Would you cons

[Read the thread](https://github.com/DavidFuchs/mcp-uptime-kuma/issues/66) · 2026-07-29 · closed · outside contributor · 1 comment

## Most recent

### DX: misspelled `monitorId` reports "expected number, received nan" for `monitorID`; and listMonitors has no way to filter by parent

Two small usability items, both about a caller being unable to tell that an argument didn't land.

## 1. `z.coerce.number()` turns a misspelled param into a confusing NaN error

`getMonitor` and `getHeartbeats` take `monitorID`. Passing the very natural `monitorId`
(lowercase d) gives:

MCP error -32602: Input validation error: Invalid arguments for tool getMonitor: [ { "code": "invalid_type", "expected": "number", "received": "nan", "path": ["monitorID"], "message": "Expected number,

Read the thread · 2026-07-26 · closed · outside contributor · 1 comment

"Not authenticated with Uptime Kuma" is permanent for the process — isAuthenticated is a write-once latch, stdio serves tools before auth completes, and no socket call has a timeout

Summary

A server that fails or stalls its one startup authentication stays alive, keeps advertising all 34 tools, and answers every one of them with MCP error -32603: Not authenticated with Uptime Kuma — for the rest of the process's life. There is no in-band recovery; the only fix is for the user to restart their MCP client.

Three separate design details combine to produce this:

1. isAuthenticated is write-once. dist/server.js:61 declares let isAuthenticated = false; it is set

Read the thread · 2026-07-26 · closed · outside contributor · 0 comments

updateMonitor cannot re-parent — parent missing from its inputSchema, call reports "Saved." while silently discarding it

Summary

createMonitor accepts parent; updateMonitor does not declare it. Because the MCP SDK strips undeclared fields, updateMonitor { monitorID, parent } returns {ok: true, monitorID, msg: "Saved."} while the monitor stays in its original group.

Same class as #58 (description) and #60 (json-query / push_token), but with a sharper edge: the other two leave a monitor impoverished, while this one makes a **successful-looking call a no-op on an operation that has no other

Read the thread · 2026-07-26 · closed · outside contributor · 0 comments

getMonitorSummary returns stale status/msg for push-type monitors

Summary

getMonitorSummary returns a stale status/msg for push-type monitors — it appears to reflect an old heartbeat (in one case, the very first heartbeat ever recorded for that monitor) rather than the most recent one. Direct SQLite queries against the Kuma database show the monitors are actually status=1 (OK, up-to-date) at the time getMonitorSummary reports them as DOWN/PENDING.

Environment

Read the thread · 2026-07-24 · open · external user · 0 comments

createMonitor / updateMonitor missing json-query fields (json_path, json_path_operator, expected_value) and push_token

Summary

Two monitor types can be created but not configured, in the same class as #41 (tags), #42 (docker), #50 (dns) and #58 (description) — the fields aren't declared in the tool inputSchema, so they're stripped before reaching the Kuma client.

json-query — no json_path, json_path_operator, or expected_value. A json-query monitor created through the MCP has no query to run. Since both schemas set additionalProperties: false, passing the fields anyway is silently discar

Read the thread · 2026-07-22 · closed · outside contributor · 0 comments

get_heartbeats / get_monitor_summary return the oldest heartbeats instead of the newest

Summary

getHeartbeats/getMonitorSummary report stale data: with maxHeartbeats: 5 I received heartbeats from six weeks ago (including an old DOWN status-change presented as if current), while the Uptime Kuma DB showed healthy heartbeats through the present moment.

Root cause

Uptime Kuma emits the connect-time heartbeatList socket.io event in ascending (oldest-first) order. uptime-kuma-client.ts stores that payload verbatim into heartbeatListCache:

this.heartbeatListC

[Read the thread](https://github.com/DavidFuchs/mcp-uptime-kuma/issues/56) · 2026-07-18 · closed · outside contributor · 0 comments

### DNS monitors cannot be configured: dns_resolve_server / dns_resolve_type not exposed — createMonitor produces a monitor that always fails

## Environment
- @davidfuchs/mcp-uptime-kuma 0.7.0 (npx, stdio transport)
- Uptime Kuma 2.4.0 (louislam/uptime-kuma:2)
- Client: Claude Code

## Summary
Neither `createMonitor` nor `updateMonitor` exposes the DNS-monitor fields
`dns_resolve_server` and `dns_resolve_type`. Both input schemas declare
`additionalProperties: false`, and passing the fields anyway returns
`{"ok": true, "msg": "Saved."}` while silently dropping them.

Consequences:

1. **`createMonitor` with `type: "dns"` produces a mo

[Read the thread](https://github.com/DavidFuchs/mcp-uptime-kuma/issues/50) · 2026-07-02 · closed · external user · 0 comments

### listTags returns empty — tagList event never emitted by Uptime Kuma on login; needs active getTags fetch

## Bug

`listTags` always returns `[]` even when tags exist in Uptime Kuma — 
and even after fixing the object/array parsing issue in `setupTagListListeners()`.

## Root cause

Uptime Kuma does **not** emit the `tagList` socket event automatically after 
login, unlike `monitorList`, `heartbeatList`, `notificationList` etc. which are 
all pushed by the server on login. The passive listener in `setupTagListListeners()` 
therefore never fires, leaving `tagListCache` permanently empty.

## Fix

Add 

[Read the thread](https://github.com/DavidFuchs/mcp-uptime-kuma/issues/46) · 2026-06-15 · closed · external user · 1 comment

### listTags always returns empty array — tagList socket event parsed as Array instead of Object

## Bug

`listTags` always returns `[]`, even when tags exist in Uptime Kuma.

## Root cause

In `uptime-kuma-client.ts`, `setupTagListListeners()` expects `tagList` to be an `Array`:

```typescript
this.socket.on('tagList', (tagList: Array<{ id: number; name: string; color: string }>) => {
  this.safeLog('debug', `Received tagList with ${tagList.length} tags`);
  this.tagListCache = tagList;
});

But Uptime Kuma sends tagList as a plain object (`{ "1": { id: 1, name: "...", color: "..." },

Read the thread · 2026-06-15 · closed · external user · 0 comments

The remaining reports are on the project's issue tracker.