mcp-uptime-kuma

List Monitors

listMonitors

Retrieve configuration details for all uptime monitors, including URLs and check intervals. Filter by type, status, tags, or parent group to examine or modify monitor settings.

Instructions

Retrieves configuration details for all monitors (URLs, check intervals, notification settings, etc.). Use this when you need to examine or modify monitor settings. For status checks ("how is everything doing?", "what's down?"), use getMonitorSummary instead. By default returns only common fields plus runtime data (uptime, avgPing); set includeTypeSpecificFields to true to include type-specific fields (e.g., url for HTTP, hostname/port for TCP). Supports filtering by keywords, type, active/maintenance status, tags, and parent group.

Input Schema

Name	Required	Description
`tags`	No	Filter by tag name and optional value. Comma-separated for multiple tags. Format: "tagName" or "tagName=value". Monitor must have all specified tags. Case-insensitive. Examples: "production", "env=staging", "production,region=us-east"
`type`	No	Filter by monitor type(s). Comma-separated for multiple types. Use listMonitorTypes tool to see all available types.
`active`	No	Filter by active status. true=only active monitors, false=only inactive monitors.
`keywords`	No	Space-separated keywords to filter monitors by pathName (case-insensitive fuzzy match). All keywords must match for a monitor to be included.
`parentId`	No	Filter to the DIRECT children of this group monitor. Pass null for top-level monitors (those with no parent). Not recursive — use the group's own childrenIDs to walk deeper.
`maintenance`	No	Filter by maintenance status. true=only monitors in maintenance, false=only monitors not in maintenance.
`includeSecrets`	No	Return credentials in full instead of "***". Off by default: this output is persisted in conversation transcripts and logs. Can also be enabled globally with UPTIME_KUMA_INCLUDE_SECRETS=true.
`includeTypeSpecificFields`	No	Include type-specific fields (url, hostname, port, etc.) in addition to common fields. Default: false. When false, only returns MonitorBase fields plus uptime/avgPing.

Output Schema

Name	Required	Description	Default
`count`	Yes
`monitors`	Yes	Array of monitor objects with common fields plus uptime/avgPing. May include type-specific fields when includeTypeSpecificFields is true. Credentials (pushToken, basic_auth_pass, bearer_token, headers, ...) read "***" unless includeSecrets is set.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.11.22Oct 7, 2026
- changedOutput schema / properties / monitors / items / properties / interval / description
```
Previous value: -"Check interval in seconds (20-2073600)"New value: +"Check interval in seconds (min 20; no upper bound since Uptime Kuma 2.5.0)"
```
- removedOutput schema / properties / monitors / items / properties / interval / maximum
```
Removed value: -2073600
```

Changed3 schema fields changedv0.11.9Aug 21, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedInput schema / properties / parentId / anyOf

Previous value: -[
-  {
-    "type": "null"
-  },
-  {
-    "type": "integer"
-  }
-]New value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv0.0.0-devAug 7, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the behavioral burden. It usefully discloses that the default return is limited to common fields plus runtime data, and that includeTypeSpecificFields expands the result; however, it does not mention pagination or secret-exposure behavior, though the latter is covered by the parameter schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose, then usage guidance, alternative routing, default behavior, and filter support. Every sentence contributes information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given eight optional parameters, an output schema, and 100% schema coverage, the description supplies enough context to call the tool correctly: purpose, when to use, sibling alternative, default return fields, type-specific toggle, and filter categories. Return-value details are appropriately left to the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all eight parameters thoroughly. The description summarizes filter categories and the includeTypeSpecificFields default, but adds little syntax or meaning beyond what the schema provides, matching the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: retrieves configuration details for all monitors, with examples of fields returned. It also explicitly differentiates from getMonitorSummary for status-checking use cases, so an agent can distinguish it from a sibling without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear when-to-use guidance ('examine or modify monitor settings') and names the alternative for status checks: getMonitorSummary. It also summarizes filtering options, so the agent knows how to narrow results.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.