Skip to main content
Glama
DavidFuchs

mcp-uptime-kuma

by DavidFuchs

Update Monitor

updateMonitor

Update an existing monitor configuration by providing its monitor ID and only the fields to change; all other settings stay unchanged. Fetch the current config with getMonitor first.

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

TableJSON Schema
NameRequiredDescriptionDefault
urlNoURL to monitor
bodyNoHTTP request body
nameNoDisplay name
portNoPort number
tagsNoTags to assign
activeNoWhether the monitor is active
methodNoHTTP method
parentNoParent group monitor ID — re-parents this monitor into that group. Pass null to move it to the top level.
headersNoHTTP headers as JSON string
keywordNoKeyword to search for
timeoutNoRequest 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.
hostnameNoHostname
intervalNoCheck interval in seconds
jsonPathNoJSONata expression for json-query monitors. Must resolve to a primitive.
parentIDNoAlias for parent. Prefer parent.
ignoreTlsNoIgnore TLS/SSL errors
json_pathNoAlias for jsonPath (the database column name). Prefer jsonPath.
monitorIDYesThe ID of the monitor to update
parent_idNoAlias for parent. Prefer parent.
pushTokenNoPush token — the secret in the ping URL. Changing it invalidates the existing URL and any sender still using it stops beating.
maxretriesNoMax retries before marking as down
push_tokenNoAlias for pushToken (the database column name). Prefer pushToken.
upsideDownNoInvert status
descriptionNoFree-text description shown on the monitor page
docker_hostNoDocker host ID (required for docker type). Use listDockerHosts to find available IDs.
maxredirectsNoMax HTTP redirects
expectedValueNoThreshold the json-query result is compared against, stored as a string.
invertKeywordNoInvert keyword match
retryIntervalNoRetry interval in seconds
expected_valueNoAlias for expectedValue. Prefer expectedValue.
resendIntervalNoResend notification every N checks while down (0 = disabled)
dns_resolve_typeNoDNS record type to query (for dns type)
docker_containerNoDocker container name (required for docker type)
jsonPathOperatorNoComparison operator for json-query monitors.
dns_resolve_serverNoDNS server to use for resolution (for dns type)
json_path_operatorNoAlias for jsonPathOperator. Prefer jsonPathOperator.
notificationIDListNoNotification ID map
accepted_statuscodesNoAccepted HTTP status codes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
msgNo
monitorIDNo
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses a critical behavioral trait: 'Only the fields you provide will be changed (the server merges your changes with the existing config).' This partial-update semantics is non-obvious and valuable. It does not cover permission requirements, errors, or response format, but the merge behavior and the prefetch recommendation provide strong transparency for this mutation tool.

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 two sentences with no wasted words. It front-loads the purpose, then states the key requirement, merge behavior, and best practice. Every sentence earns its place.

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?

Despite the 38-parameter complexity, the description is complete enough because the input schema thoroughly documents each parameter (including aliases, enums, and field-specific warnings like pushToken invalidation). The description adds the essential workflow guidance (getMonitor first, partial merge, required ID), and an output schema exists, so return values need not be described. The combination of schema and description covers the tool's scope well.

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?

The schema has 100% parameter description coverage, so the baseline is 3. The description adds meaningful parameter-related semantics beyond the schema: it clarifies that unspecified parameters retain their existing values due to server-side merging. This contextualizes all optional parameters and the required monitorID, going beyond the schema's per-field descriptions.

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?

The description uses a specific verb+resource: 'Updates an existing monitor configuration.' It clearly distinguishes from createMonitor (for new monitors), getMonitor (read), deleteMonitor (removal), and other update tools for different resources. The phrase 'existing' plus 'monitorID' reinforces the target.

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?

The description provides clear context: 'You must include the monitorID' and 'Use getMonitor first to get the current config.' This gives practical guidance for correct invocation. However, it does not explicitly state when not to use this tool or name alternatives like createMonitor for new monitors, so it stops short of full explicit exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DavidFuchs/mcp-uptime-kuma'

If you have feedback or need assistance with the MCP directory API, please join our Discord server