Skip to main content
Glama
DavidFuchs

mcp-uptime-kuma

by DavidFuchs

Create Monitor

createMonitor

Create a new monitor in Uptime Kuma with type-specific settings (URL, hostname, port, etc.) to start tracking uptime.

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. 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

TableJSON Schema
NameRequiredDescriptionDefault
urlNoURL to monitor (required for http/keyword/json-query types)
bodyNoHTTP request body
nameYesDisplay name for the monitor
portNoPort number (required for port/tcp types)
tagsNoTags to assign to the monitor
typeYesMonitor type (e.g. http, port, ping, dns, push, keyword). Use listMonitorTypes for all options.
activeNoWhether the monitor starts checking immediately (default: true). Pass false to create it paused.
methodNoHTTP method (GET, POST, etc.) for http type
parentNoParent group monitor ID
headersNoHTTP headers as JSON string
keywordNoKeyword to search for (keyword monitor type)
timeoutNoRequest 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.
hostnameNoHostname to monitor (required for port/ping/dns types)
intervalNoCheck interval in seconds (default: 60)
jsonPathNoJSONata expression for json-query monitors. Must resolve to a primitive.
ignoreTlsNoIgnore TLS/SSL errors
json_pathNoAlias for jsonPath (the database column name). Prefer jsonPath.
pushTokenNoPush token for push monitors — the secret in the ping URL. Omit and one is generated and returned.
maxretriesNoMax retries before marking as down (default: 0)
push_tokenNoAlias for pushToken (the database column name). Prefer pushToken.
upsideDownNoInvert status — treat up as down
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 (default: 10)
expectedValueNoThreshold the json-query result is compared against. Stored as a string.
invertKeywordNoInvert keyword match
retryIntervalNoRetry interval in seconds when monitor is down (default: 60)
expected_valueNoAlias for expectedValue. Prefer expectedValue.
resendIntervalNoResend notification every N checks while down (0 = disabled, the default)
dns_resolve_typeNoDNS record type to query (required for dns type, default: A)
docker_containerNoDocker container name (required for docker type)
jsonPathOperatorNoComparison operator for json-query monitors. UP while value <operator> expectedValue.
dns_resolve_serverNoDNS server to use for resolution (required for dns type, default: 1.1.1.1)
json_path_operatorNoAlias for jsonPathOperator. Prefer jsonPathOperator.
notificationIDListNoMap of notification IDs to enable (e.g. {"1": true, "3": true})
accepted_statuscodesNoAccepted HTTP status codes (e.g. ["200-299"])

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
msgNo
pushURLNoPush monitors only. The URL the sender should GET.
timeoutNoThe timeout in seconds actually stored, including the default applied when omitted.
monitorIDNo
pushTokenNoPush monitors only. The token, so the sender can be wired up without a second, wider read.
Behavior3/5

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

With no annotations, the description carries full burden. It discloses non-obvious push monitor token generation and the returned ping URL, plus a timeout default caveat. However, it does not mention side effects like active-by-default behavior, duplicate name errors, or permission requirements, leaving gaps for a create 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?

Three sentences, each with a distinct purpose: state the action, give type-specific parameter guidance, and disclose push/timeout behavior. No redundant filler; the purpose is front-loaded.

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 tool with 36 parameters and an output schema, the description covers essential cross-parameter requirements and a critical behavioral caveat. The high schema coverage and output schema mitigate the need for exhaustive description, and the reference to listMonitorTypes aids navigation. It does not fully detail all possible side effects, but it is sufficiently complete for an AI agent.

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 100%, so baseline is 3. The description adds meaning by grouping parameters by monitor type (e.g., 'for TCP/port include hostname and port') and by explaining push token generation and timeout default. This synthesis helps the agent select the correct parameter set, going beyond individual schema 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 clearly states 'Creates a new monitor in Uptime Kuma' with a specific verb and resource. It distinguishes from sibling CRUD tools like updateMonitor and deleteMonitor, and specifies required minimum fields (name and type).

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 explicit, type-based parameter guidance (HTTP, TCP/port, json-query, push) and references listMonitorTypes as a discovery tool. However, it does not explicitly state when not to use the tool (e.g., 'for updates, use updateMonitor'), so it falls short of full when-not coverage.

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