fettle-mcp

Overview Schema Source Related Servers Discussions Admin

Create several monitors

bulk_create_monitors

Create up to 100 uptime monitors in one all-or-nothing call. Check plan usage first; if any item fails validation, the batch is rejected and no monitors are created.

Instructions

Create 1 to 100 monitors in one call, all or nothing; for a single monitor use create_monitor. Requires a key with the write scope. An invalid item, or a batch that would exceed the plan, rejects the whole call and creates nothing: call get_plan_usage first to check the batch fits. Errors name the failing item. A field that fails validation is named by its path, such as monitors.3.target (index 3 is the fourth item; all such errors are reported at once). Any other item error keeps the status create_monitor would give (403 when its interval or regions break the plan or name an unknown region, 404 for an unknown channel id, 422 for its config or its type's region rules) and its reason starts with monitors[3] (""): — only the first such item is reported. Read the index only from that leading monitors[N] (the pattern ^monitors[(\d+)] after any lead-in such as "Forbidden: " or "Invalid request: "), never from the name, which may itself contain quotes or brackets. A plan-limit 403 without that prefix is about the batch as a whole: together the items would exceed the plan's monitor count or its quota of monitors below 60 seconds. Fix the item or shrink the batch and send the whole call again. Returns monitors: one list_monitors row per created monitor, in request order. Example: {"monitors": [{"name": "db.example.com exposed ports", "type": "TCP", "target": "db.example.com", "interval_seconds": 3600, "timeout_seconds": 10, "regions": ["eu-central"], "config": {"ports": [5432, 6379, 27017], "expected_state": "closed"}}]}

Input Schema

TableJSON Schema

Name	Required	Description	Default
`monitors`	Yes	1 to 100 monitors, each taking the same fields and rules as create_monitor's arguments. Items with is_active false are created paused and still count toward the plan.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`monitors`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.6.1Oct 20, 2026

changedInput schema / properties / monitors / description

Previous value: -"Monitors to create, each shaped like a single create request."New value: +"1 to 100 monitors, each taking the same fields and rules as create_monitor's arguments. Items with is_active false are created paused and still count toward the plan."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "monitors": {
+      "items": {
+        "properties": {
+          "id": {
+            "format": "uuid",
+            "type": "string"
+          },
+          "interval_seconds": {
+            "type": "integer"
+          },
+          "is_active": {
+            "type": "boolean"
+          },
+          "last_checked_at": {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "name": {
+            "type": "string"
+          },
+          "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"
+          },
+          "type": {
+            "description": "Known values: HTTP, PING, SSL, TCP, DNS.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "name",
+          "type",
+          "target",
+          "status",
+          "is_active",
+          "interval_seconds",
+          "ssl_expires_at",
+          "last_checked_at"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "monitors"
+  ],
+  "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?

Goes well beyond the annotations: atomicity (nothing is created on any failure), plan-limit behavior, per-item vs batch error discrimination, the exact status codes inherited from create_monitor (403/404/422), and the monitors[N] prefix contract for locating the offending item. This is exactly the kind of operational detail annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the create_monitor alternative are front-loaded, but the long middle paragraph about regex-parsing the monitors[N] prefix ('only the first such item is reported', quoting several lead-in variants) is verbose and could be tightened without losing meaning. It is information-dense rather than padded, but not as lean as it could be.

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?

An output schema exists, yet the description still adds the ordering guarantee ('one list_monitors row per created monitor, in request order'), which the schema alone may not convey. Combined with atomicity, prerequisite checks, and error semantics, an agent has everything needed for a 100-item batch call.

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 description coverage is 100%, so the schema already documents the field set and rules. The description adds value with a complete worked example payload (TCP monitor with ports config) and clarifies error-path semantics like monitors.3.target, but does not restate field-level constraints, keeping it modestly above the baseline.

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 ('Create 1 to 100 monitors in one call') plus the batch cardinality and all-or-nothing semantics, and explicitly distinguishes from the sibling create_monitor for the single-item case. An agent can identify the tool 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 explicit routing ('for a single monitor use create_monitor') and an actionable prerequisite ('call get_plan_usage first to check the batch fits'). The failure-and-retry guidance ('Fix the item or shrink the batch and send the whole call again') tells the agent how to recover, which is rare and genuinely useful.

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

Deploy Server