mcp-uptime-kuma

Update Monitor

updateMonitor

Update an existing Uptime Kuma monitor's configuration by ID. Only supplied fields change; all other settings stay intact.

Instructions

Updates an existing monitor configuration. You must include the monitorID. Only the fields you provide will be changed (the server merges your changes with the existing config). Use getMonitor first to get the current config.

Input Schema

Name	Required	Description
`url`	No	URL to monitor
`body`	No	HTTP request body
`name`	No	Display name
`port`	No	Port number
`tags`	No	Tags to assign
`active`	No	Whether the monitor is active
`method`	No	HTTP method
`parent`	No	Parent group monitor ID — re-parents this monitor into that group. Pass null to move it to the top level.
`headers`	No	HTTP headers as JSON string
`keyword`	No	Keyword to search for
`timeout`	No	Request timeout in SECONDS. Avoid 0 — Uptime Kuma's runtime fallback for a stored 0 yields a ~13 hour timeout, so the monitor can never report DOWN against a black-holed endpoint.
`hostname`	No	Hostname
`interval`	No	Check interval in seconds
`jsonPath`	No	JSONata expression for json-query monitors. Must resolve to a primitive.
`parentID`	No	Alias for parent. Prefer parent.
`ignoreTls`	No	Ignore TLS/SSL errors
`json_path`	No	Alias for jsonPath (the database column name). Prefer jsonPath.
`monitorID`	Yes	The ID of the monitor to update
`parent_id`	No	Alias for parent. Prefer parent.
`pushToken`	No	Push token — the secret in the ping URL. Changing it invalidates the existing URL and any sender still using it stops beating.
`maxretries`	No	Max retries before marking as down
`push_token`	No	Alias for pushToken (the database column name). Prefer pushToken.
`upsideDown`	No	Invert status
`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
`databaseQuery`	No	Query for database monitors. SQL for mysql, postgres and sqlserver; a JSON command object for mongodb.
`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
`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)
`databasePassword`	No	Password for mysql monitors, stored by Uptime Kuma as radiusPassword. Sending "***" back keeps the stored value.
`dns_resolve_type`	No	DNS record type to query (for dns type)
`docker_container`	No	Docker container name (required for docker type)
`jsonPathOperator`	No	Comparison operator for json-query monitors.
`dns_resolve_server`	No	DNS server to use for resolution (for dns type)
`json_path_operator`	No	Alias for jsonPathOperator. Prefer jsonPathOperator.
`notificationIDList`	No	Notification ID map
`accepted_statuscodes`	No	Accepted HTTP status codes
`databaseConnectionString`	No	Connection string for mysql, postgres, mongodb, redis and sqlserver monitors. A credential: read tools return "*", and sending "*" back keeps the stored value.
`database_connection_string`	No	Alias for databaseConnectionString (the database column name). Prefer databaseConnectionString.

Output Schema

Name	Required	Description	Default
`ok`	Yes
`msg`	No
`monitorID`	No

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. A credential: read tools return \"***\", and sending \"***\" back keeps the stored value.",
+  "type": "string"
+}

addedInput schema / properties / databasePassword

Added value: +{
+  "description": "Password for mysql monitors, stored by Uptime Kuma as radiusPassword. Sending \"***\" back keeps the stored value.",
+  "type": "string"
+}

addedInput schema / properties / databaseQuery

Added value: +{
+  "description": "Query for database monitors. SQL for mysql, postgres and sqlserver; a JSON command object for mongodb.",
+  "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"
+}

Changed4 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 / 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/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and delivers the key non-obvious behavior: this is a partial-update/merge operation where unprovided fields are preserved, not overwritten. It does not disclose permission needs, reversibility, or that writing '***' preserves stored secrets — though the schema covers the latter — so a small gap remains for a 44-parameter mutation.

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?

Three short sentences, each earning its place: identity requirement first, then merge behavior, then the recommended follow-up call. No repetition of schema fields, no filler.

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?

Given a rich 44-parameter schema with full descriptions and an output schema, the description covers what an agent most needs to avoid a destructive mistake: the ID is required and updates merge rather than replace. It could do slightly more about type-specific fields and alias preferences, which is the main remaining risk area.

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 baseline is 3. The description adds the merge semantics ('only the fields you provide will be changed') and the monitorID requirement, which are real value, but it does not address the large alias set (parent/parentID/parent_id, pushToken/push_token, jsonPath/json_path) or type-specific required fields that dominate this schema.

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

Purpose4/5

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

The description opens with a specific verb+resource pair ('Updates an existing monitor configuration') and immediately narrows scope to existing monitors via the required monitorID. It doesn't explicitly contrast with createMonitor, but 'existing' does enough to separate the two in practice.

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?

It gives an explicit prerequisite workflow: 'Use getMonitor first to get the current config,' naming the sibling to call. Missing is any when-not guidance (e.g. use pauseMonitor to toggle active state, or createMonitor for new monitors), so it stops short of a full routing rule.

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