fettle-mcp

Overview Schema Source Related Servers Discussions Admin

Check a monitor now

check_now

Queue an existing monitor to run on the scheduler's next tick instead of waiting for its interval, useful for confirming a fix. Call get_monitor or list_check_results shortly after for the outcome.

Instructions

Queue one existing monitor to run on the scheduler's next tick instead of waiting out its interval, for example to confirm a fix. It returns the monitor record, not a check result: call get_monitor or list_check_results a moment later for the outcome. To probe a target that has no monitor yet use check_target; to restart a paused monitor use resume_monitor. Requires a key with the write scope. A repeat call for the same monitor within 30 seconds, or a call on a paused monitor, is a silent no-op that returns it unchanged. Calls are limited to 10 per minute per calling address (not per key or organization); past that it is a 429 with the seconds to wait, so pace a run over many monitors.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`monitor_id`	Yes	The monitor's uuid from list_monitors. An id that is not a monitor of this organization, or a deleted one, is a 404.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`name`	Yes
`tags`	No
`type`	Yes	Known values: HTTP, PING, SSL, TCP, DNS.
`config`	Yes
`status`	Yes	Known values: PENDING, UP, DEGRADED, DOWN, PAUSED.
`target`	Yes
`regions`	Yes
`user_id`	Yes
`is_active`	Yes
`created_at`	Yes
`updated_at`	Yes
`channel_ids`	No
`next_run_at`	Yes
`badge_enabled`	No
`ssl_cert_info`	No
`ssl_expires_at`	Yes
`last_checked_at`	Yes
`region_statuses`	Yes	Per-region latest status, sorted by region name. Built from ``region_snapshots``; ``job_id`` is dropped (internal dedup key) and malformed/partial snapshot rows are skipped rather than failing the read.
`timeout_seconds`	Yes
`interval_seconds`	Yes
`confirmation_threshold`	Yes
`notification_cooldown_seconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.6.1Oct 20, 2026

addedInput schema / properties / monitor_id / description

Added value: +"The monitor's uuid from list_monitors. An id that is not a monitor of this organization, or a deleted one, is a 404."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "badge_enabled": {
+      "type": "boolean"
+    },
+    "channel_ids": {
+      "items": {
+        "format": "uuid",
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "config": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "confirmation_threshold": {
+      "type": "integer"
+    },
+    "created_at": {
+      "type": "string"
+    },
+    "id": {
+      "format": "uuid",
+      "type": "string"
+    },
+    "interval_seconds": {
+      "type": "integer"
+    },
+    "is_active": {
+      "type": "boolean"
+    },
+    "last_checked_at": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "name": {
+      "type": "string"
+    },
+    "next_run_at": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "notification_cooldown_seconds": {
+      "type": "integer"
+    },
+    "region_statuses": {
+      "description": "Per-region latest status, sorted by region name.\n\nBuilt from ``region_snapshots``; ``job_id`` is dropped (internal\ndedup key) and malformed/partial snapshot rows are skipped rather\nthan failing the read.",
+      "items": {
+        "properties": {
+          "checked_at": {
+            "type": "string"
+          },
+          "display_name": {
+            "type": "string"
+          },
+          "region": {
+            "type": "string"
+          },
+          "status": {
+            "description": "Known values: UP, DEGRADED, DOWN, ERROR.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "region",
+          "status",
+          "checked_at",
+          "display_name"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "regions": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "ssl_cert_info": {
+      "anyOf": [
+        {
+          "properties": {
+            "issuer": {
+              "anyOf": [
+                {
+                  "type": "string"
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            },
+            "not_after": {
+              "anyOf": [
+                {
+                  "type": "string"
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            },
+            "not_before": {
+              "anyOf": [
+                {
+                  "type": "string"
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            },
+            "subject": {
+              "anyOf": [
+                {
+                  "type": "string"
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            },
+            "valid": {
+              "anyOf": [
+                {
+                  "type": "boolean"
+                },
+                {
+                  "type": "null"
+                }
+              ]
+            }
+          },
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "ssl_expires_at": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "status": {
+      "description": "Known values: PENDING, UP, DEGRADED, DOWN, PAUSED.",
+      "type": "string"
+    },
+    "tags": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "target": {
+      "type": "string"
+    },
+    "timeout_seconds": {
+      "type": "integer"
+    },
+    "type": {
+      "description": "Known values: HTTP, PING, SSL, TCP, DNS.",
+      "type": "string"
+    },
+    "updated_at": {
+      "type": "string"
+    },
+    "user_id": {
+      "format": "uuid",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "user_id",
+    "name",
+    "type",
+    "target",
+    "interval_seconds",
+    "timeout_seconds",
+    "regions",
+    "config",
+    "status",
+    "last_checked_at",
+    "next_run_at",
+    "confirmation_threshold",
+    "notification_cooldown_seconds",
+    "ssl_expires_at",
+    "is_active",
+    "created_at",
+    "updated_at",
+    "region_statuses"
+  ],
+  "type": "object"
+}

First observedv0.5.4Oct 20, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations declare the safety profile, but the description adds substantial non-structured context: it returns the monitor record rather than a check result, the 30-second and paused-monitor no-op semantics, the write scope requirement, and a per-address rate limit with 429 behavior and a pacing recommendation. This is exactly the operational detail an agent needs before calling.

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?

Front-loaded with the core action and effect, then layered: return-value caveat, sibling routing, auth requirement, no-op conditions, rate limit. Every sentence carries actionable information with no padding.

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?

Covers the gaps an output schema cannot: latency of the result, silent no-op conditions, auth scope, and rate limiting with pacing guidance. The explicit note that the return is the monitor record, not a check result, is the key clarification for correct agent follow-up.

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% and the single parameter is fully documented there (uuid source from list_monitors, 404 conditions). The description adds no additional parameter-level syntax or format meaning, 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 ('Queue one existing monitor to run on the scheduler's next tick instead of waiting out its interval') and explicitly distinguishes itself from check_target and resume_monitor. The purpose and scope are unambiguous 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 Guidelines5/5

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

Gives an explicit use case ('to confirm a fix'), names two sibling alternatives with the condition that selects each (check_target for no monitor yet, resume_monitor for a paused monitor), and flags the silent no-op cases that make the call pointless. Nothing is left to inference.

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

Deploy Server