mcp-uptime-kuma

Create Monitor

createMonitor

Creates Uptime Kuma monitors for HTTP, TCP, ping, DNS, push, and database checks. Provide a name and type plus type-specific settings to start monitoring or create a paused monitor.

Instructions

Creates a new monitor in Uptime Kuma. Requires at minimum a name and type. Use listMonitorTypes to see supported types. For HTTP monitors include url; for TCP/port monitors include hostname and port; for json-query include url, jsonPath, jsonPathOperator and expectedValue; for database types (mysql, postgres, mongodb, redis, sqlserver) include databaseConnectionString. A push monitor is given a generated push token (Uptime Kuma only generates one in its own web UI) and the resulting ping URL is returned. timeout defaults to 0.8 x interval seconds for polled types.

Input Schema

Name	Required	Description
`url`	No	URL to monitor (required for http/keyword/json-query types)
`body`	No	HTTP request body
`name`	Yes	Display name for the monitor
`port`	No	Port number (required for port/tcp types)
`tags`	No	Tags to assign to the monitor
`type`	Yes	Monitor type (e.g. http, port, ping, dns, push, keyword). Use listMonitorTypes for all options.
`active`	No	Whether the monitor starts checking immediately (default: true). Pass false to create it paused.
`method`	No	HTTP method (GET, POST, etc.) for http type
`parent`	No	Parent group monitor ID
`headers`	No	HTTP headers as JSON string
`keyword`	No	Keyword to search for (keyword monitor type)
`timeout`	No	Request timeout in SECONDS. Omit for 0.8 x interval. Avoid 0: Uptime Kuma's runtime fallback for a stored 0 computes interval * 1000 * 0.8 and then multiplies by 1000 again, yielding a ~13 hour timeout, so the monitor can never report DOWN against a host that accepts the connection and never answers.
`hostname`	No	Hostname to monitor (required for port/ping/dns types)
`interval`	No	Check interval in seconds (default: 60)
`jsonPath`	No	JSONata expression for json-query monitors. Must resolve to a primitive.
`ignoreTls`	No	Ignore TLS/SSL errors
`json_path`	No	Alias for jsonPath (the database column name). Prefer jsonPath.
`pushToken`	No	Push token for push monitors — the secret in the ping URL. Omit and one is generated and returned.
`maxretries`	No	Max retries before marking as down (default: 0)
`push_token`	No	Alias for pushToken (the database column name). Prefer pushToken.
`upsideDown`	No	Invert status — treat up as down
`description`	No	Free-text description shown on the monitor page
`docker_host`	No	Docker host ID (required for docker type). Use listDockerHosts to find available IDs.
`maxredirects`	No	Max HTTP redirects (default: 10)
`databaseQuery`	No	Query for database monitors. SQL for mysql, postgres and sqlserver (default: SELECT 1); a JSON command object for mongodb (default: {"ping": 1}).
`expectedValue`	No	Threshold the json-query result is compared against. Stored as a string.
`invertKeyword`	No	Invert keyword match
`retryInterval`	No	Retry interval in seconds when monitor is down (default: 60)
`database_query`	No	Alias for databaseQuery (the database column name). Prefer databaseQuery.
`expected_value`	No	Alias for expectedValue. Prefer expectedValue.
`radiusPassword`	No	The column databasePassword is stored in; also the RADIUS password. Prefer databasePassword for mysql.
`resendInterval`	No	Resend notification every N checks while down (0 = disabled, the default)
`databasePassword`	No	Password for mysql monitors, if not inline in the connection string. Stored by Uptime Kuma as radiusPassword. A credential: read tools return it as "***".
`dns_resolve_type`	No	DNS record type to query (required for dns type, default: A)
`docker_container`	No	Docker container name (required for docker type)
`jsonPathOperator`	No	Comparison operator for json-query monitors. UP while value <operator> expectedValue.
`dns_resolve_server`	No	DNS server to use for resolution (required for dns type, default: 1.1.1.1)
`json_path_operator`	No	Alias for jsonPathOperator. Prefer jsonPathOperator.
`notificationIDList`	No	Map of notification IDs to enable (e.g. {"1": true, "3": true})
`accepted_statuscodes`	No	Accepted HTTP status codes (e.g. ["200-299"])
`databaseConnectionString`	No	Connection string for mysql, postgres, mongodb, redis and sqlserver monitors (required for those types). A credential: read tools return it as "***" unless includeSecrets is set.
`database_connection_string`	No	Alias for databaseConnectionString (the database column name). Prefer databaseConnectionString.

Output Schema

Name	Required	Description
`ok`	Yes
`msg`	No
`pushURL`	No	Push monitors only. The URL the sender should GET.
`timeout`	No	The timeout in seconds actually stored, including the default applied when omitted.
`monitorID`	No
`pushToken`	No	Push monitors only. The token, so the sender can be wired up without a second, wider read.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv0.12.1Oct 26, 2026

addedInput schema / properties / databaseConnectionString

Added value: +{
+  "description": "Connection string for mysql, postgres, mongodb, redis and sqlserver monitors (required for those types). A credential: read tools return it as \"***\" unless includeSecrets is set.",
+  "type": "string"
+}

addedInput schema / properties / databasePassword

Added value: +{
+  "description": "Password for mysql monitors, if not inline in the connection string. Stored by Uptime Kuma as radiusPassword. A credential: read tools return it as \"***\".",
+  "type": "string"
+}

addedInput schema / properties / databaseQuery

Added value: +{
+  "description": "Query for database monitors. SQL for mysql, postgres and sqlserver (default: SELECT 1); a JSON command object for mongodb (default: {\"ping\": 1}).",
+  "type": "string"
+}

addedInput schema / properties / database_connection_string

Added value: +{
+  "description": "Alias for databaseConnectionString (the database column name). Prefer databaseConnectionString.",
+  "type": "string"
+}

addedInput schema / properties / database_query

Added value: +{
+  "description": "Alias for databaseQuery (the database column name). Prefer databaseQuery.",
+  "type": "string"
+}

addedInput schema / properties / radiusPassword

Added value: +{
+  "description": "The column databasePassword is stored in; also the RADIUS password. Prefer databasePassword for mysql.",
+  "type": "string"
+}

Changed6 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"

addedInput schema / properties / parent / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / parent / type
```
Removed value: -[
-  "number",
-  "null"
-]
```

addedInput schema / properties / timeout / anyOf

Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / timeout / type
```
Removed value: -[
-  "number",
-  "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.3/5.0

Behavior4/5

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

No annotations exist, so the description carries the full burden and does well: it discloses that a push monitor gets a generated token and that the resulting ping URL is returned (a non-obvious behavior not visible in the web UI), plus the timeout derivation from interval. It omits permission/precondition behavior and what happens on invalid type or duplicate name, which keeps it below 5.

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

Conciseness4/5

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

Front-loaded with the tool's action and minimum requirements, then per-type requirements, then notable behaviors. Dense but every sentence carries information; the json-query parameter enumeration is the only slightly list-heavy part.

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

Completeness4/5

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

For a 42-parameter creation tool with an output schema and full schema coverage, the description covers the required core, per-type requirements, and the non-obvious push-token behavior. Remaining gaps (credential handling, error cases) are reasonable to leave to the schema.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3, but the description adds cross-field conditional meaning the schema cannot express: which parameter set is required for each monitor type. Minor omissions like tags, notificationIDList and accepted_statuscodes are left entirely to the schema.

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 ('Creates a new monitor in Uptime Kuma') and immediately names the minimum required fields. It is unambiguously the creation counterpart to the sibling updateMonitor/deleteMonitor tools.

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

Usage Guidelines4/5

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

Gives concrete when-to-use-which-fields guidance per monitor type (url for HTTP, hostname+port for TCP, jsonPath/jsonPathOperator/expectedValue for json-query, databaseConnectionString for database types) and routes to listMonitorTypes for the type list. It does not explicitly exclude cases such as an already-existing monitor (updateMonitor) or duplicate-name failures, so it stops short of a 5.

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