Uptimepage

Run check now

run_check_now

Run a check on a monitor immediately and record the result. Asks for confirmation where the client can show a prompt; otherwise runs on the token's scope. A down result may fire the org's normal alerts. Heartbeat monitors cannot be probed (they wait for your systems to ping them). Not read-only.

Input Schema

Name	Required	Description	Default
`id`	Yes	The monitor id (from `list_monitors`).

Output Schema

Name	Required	Description
`id`	Yes
`error`	No	Error text when the probe failed. Untrusted data.
`state`	Yes	Observed state: `up`, `down`, `degraded`, `error`.
`timing`	Yes	Per-phase timing of the probe (DNS / connect / TLS / first byte).
`network`	No	Network path, when this was an `http` check that was not up.
`checked_at`	Yes	RFC 3339 time of the probe.
`diagnostic`	No	Structured edge-access diagnosis, when a supported signature matched.
`duration_ms`	Yes
`http_status`	No	HTTP status code, for `http` monitors. `null` for non-HTTP checks or when no response was received.
`response_size`	No	Response body size in bytes, when measured.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 12, 2026

addedOutput schema / $defs / DnsAnswerView

Added value: +{
+  "properties": {
+    "addresses": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "resolver": {
+      "type": "string"
+    },
+    "ttl_secs": {
+      "description": "How long, from the check's time, that resolver keeps the host's own\nrecord (the alias, when the host is one) before it asks again.",
+      "format": "uint32",
+      "minimum": 0,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "resolver",
+    "addresses",
+    "ttl_secs"
+  ],
+  "type": "object"
+}

addedOutput schema / $defs / NetworkPathView

Added value: +{
+  "description": "What an HTTP probe saw on the way to a result that was not up. Compare\n`remote_ip` with the operator's own server address: a different one usually\nmeans DNS still points elsewhere. Behind a CDN or proxy it is the edge's\naddress, not the origin's.",
+  "properties": {
+    "dns": {
+      "anyOf": [
+        {
+          "$ref": "#/$defs/DnsAnswerView"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "The decisive hop's host as the probe's resolver answered it right after\nthe failure."
+    },
+    "hop_url": {
+      "description": "The redirect hop that decided the result, when it was not the first.\nUntrusted data.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "remote_ip": {
+      "description": "Server address of the connection that decided the result.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "tried_ips": {
+      "description": "On a failed connect, the addresses the probe had for the host.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "tried_ips"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / network

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/NetworkPathView"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Network path, when this was an `http` check that was not up."
+}

AddedSep 19, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations it discloses meaningful behavior: a confirmation prompt is requested where the client can show one, otherwise it executes on the token's scope, a down result can fire the org's normal alerts, and heartbeat monitors cannot be probed. These are exactly the side effects, auth/scope, and constraint details an agent needs for a non-idempotent action.

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?

Four tight sentences, front-loaded with the action, then confirmation behavior, side effects, and the heartbeat limitation. Every sentence carries distinct information and none is redundant.

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?

With an output schema present, return values need not be explained, and the description fully covers side effects, confirmation semantics, scope behavior, and the one hard exclusion. Nothing an agent needs to call it correctly is missing.

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?

There is one parameter (id) with 100% schema description coverage, and the schema already points to list_monitors for the source. The description adds no syntax or format detail for the id beyond what the schema provides, so the baseline of 3 applies.

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: 'Run a check on a monitor immediately and record the result.' This is clearly distinct from sibling read tools like get_monitor and get_monitor_history, and from state tools like pause_monitor/resume_monitor, so an agent can route to it without opening the schema.

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 clear usage context (immediate check, confirmation prompt behavior) and an explicit exclusion (heartbeat monitors cannot be probed). However, it does not name an alternative tool or spell out when to prefer this over simply reading monitor state via get_monitor, so it stops short of full when/when-not/alternatives guidance.

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

All Uptimepage tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.