Saber

monitors-create

Create a monitor

Input Schema

TableJSON Schema

Name	Required	Description	Default
`__requestBody`	Yes	Request body

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 29, 2026

changedInput schema / properties / __requestBody / properties / checks / items / properties / type / enum

Previous value: -[
-  "job_posted",
-  "social_posted",
-  "funding_raised",
-  "investment_made",
-  "ipo_announced",
-  "ipo_stage_changed",
-  "repo_engaged",
-  "ipo_rumoured"
-]New value: +[
+  "job_posted",
+  "social_posted",
+  "funding_raised",
+  "investment_made",
+  "ipo_announced",
+  "ipo_stage_changed",
+  "repo_engaged",
+  "ipo_rumoured",
+  "tender_published"
+]

changedInput schema / properties / __requestBody / properties / webhook / allOf

Previous value: -[
-  {
-    "additionalProperties": {},
-    "properties": {
-      "interval": {
-        "enum": [
-          "daily",
-          "weekly"
-        ],
-        "type": "string"
-      },
-      "intervalSignalLimit": {
-        "description": "Maximum signals to deliver per polling interval. Each run delivers at most this many. Over a billing cycle the monitor delivers at most this value times the number of runs its interval allows in the cycle, then waits for the next cycle. When runs overlap, for example a manual trigger during a scheduled run, the cycle total can exceed this by at most one run's limit per overlapping run. For ipo_stage_changed, ipo_rumoured and repo_engaged, which Saber checks every few minutes on its own schedule, the limit bounds each check rather than each interval, and the billing-cycle bound is the effective ceiling.",
-        "maximum": 10000,
-        "minimum": 1,
-        "type": "integer"
-      },
-      "url": {
-        "description": "Delivery endpoint. Omit it to create a monitor with no delivery: signals are still detected, stored and charged, and are read back from GET /v1/monitors/{monitorId}/signals instead of being POSTed. A url-less webhook block is still accepted, and is how a caller sets interval and intervalSignalLimit without configuring delivery.",
-        "format": "uri",
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  {
-    "additionalProperties": {},
-    "properties": {
-      "secret": {
-        "description": "Optional HMAC signing secret for deliveries; never echoed back.",
-        "maxLength": 200,
-        "type": "string",
-        "writeOnly": true
-      }
-    },
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": {},
+    "properties": {
+      "interval": {
+        "enum": [
+          "daily",
+          "weekly"
+        ],
+        "type": "string"
+      },
+      "intervalSignalLimit": {
+        "description": "Maximum signals to deliver per polling interval. Each run delivers at most this many. Over a billing cycle the monitor delivers at most this value times the number of runs its interval allows in the cycle, then waits for the next cycle. When runs overlap, for example a manual trigger during a scheduled run, the cycle total can exceed this by at most one run's limit per overlapping run. For ipo_stage_changed, ipo_rumoured, repo_engaged and tender_published, which Saber checks on its own schedule (every few minutes, or every hour for tender_published), the limit bounds each check rather than each interval, and the billing-cycle bound is the effective ceiling.",
+        "maximum": 10000,
+        "minimum": 1,
+        "type": "integer"
+      },
+      "url": {
+        "description": "Delivery endpoint. Omit it to create a monitor with no delivery: signals are still detected, stored and charged, and are read back from GET /v1/monitors/{monitorId}/signals instead of being POSTed. A url-less webhook block is still accepted, and is how a caller sets interval and intervalSignalLimit without configuring delivery.",
+        "format": "uri",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  {
+    "additionalProperties": {},
+    "properties": {
+      "secret": {
+        "description": "Optional HMAC signing secret for deliveries; never echoed back.",
+        "maxLength": 200,
+        "type": "string",
+        "writeOnly": true
+      }
+    },
+    "type": "object"
+  }
+]

Changed1 schema field changedSep 15, 2026

changedInput schema / properties / __requestBody / properties / webhook / allOf

Previous value: -[
-  {
-    "additionalProperties": {},
-    "properties": {
-      "interval": {
-        "enum": [
-          "daily",
-          "weekly"
-        ],
-        "type": "string"
-      },
-      "intervalSignalLimit": {
-        "maximum": 10000,
-        "minimum": 1,
-        "type": "integer"
-      },
-      "url": {
-        "format": "uri",
-        "type": "string"
-      }
-    },
-    "required": [
-      "url"
-    ],
-    "type": "object"
-  },
-  {
-    "additionalProperties": {},
-    "properties": {
-      "secret": {
-        "description": "Optional HMAC signing secret for deliveries; never echoed back.",
-        "maxLength": 200,
-        "type": "string",
-        "writeOnly": true
-      }
-    },
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": {},
+    "properties": {
+      "interval": {
+        "enum": [
+          "daily",
+          "weekly"
+        ],
+        "type": "string"
+      },
+      "intervalSignalLimit": {
+        "description": "Maximum signals to deliver per polling interval. Each run delivers at most this many. Over a billing cycle the monitor delivers at most this value times the number of runs its interval allows in the cycle, then waits for the next cycle. When runs overlap, for example a manual trigger during a scheduled run, the cycle total can exceed this by at most one run's limit per overlapping run. For ipo_stage_changed, ipo_rumoured and repo_engaged, which Saber checks every few minutes on its own schedule, the limit bounds each check rather than each interval, and the billing-cycle bound is the effective ceiling.",
+        "maximum": 10000,
+        "minimum": 1,
+        "type": "integer"
+      },
+      "url": {
+        "description": "Delivery endpoint. Omit it to create a monitor with no delivery: signals are still detected, stored and charged, and are read back from GET /v1/monitors/{monitorId}/signals instead of being POSTed. A url-less webhook block is still accepted, and is how a caller sets interval and intervalSignalLimit without configuring delivery.",
+        "format": "uri",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  {
+    "additionalProperties": {},
+    "properties": {
+      "secret": {
+        "description": "Optional HMAC signing secret for deliveries; never echoed back.",
+        "maxLength": 200,
+        "type": "string",
+        "writeOnly": true
+      }
+    },
+    "type": "object"
+  }
+]

Changed1 schema field changedSep 8, 2026

changedInput schema / properties / __requestBody / properties / checks / items / properties / type / enum

Previous value: -[
-  "job_posted",
-  "social_posted",
-  "funding_raised",
-  "investment_made",
-  "ipo_announced",
-  "ipo_stage_changed",
-  "repo_engaged"
-]New value: +[
+  "job_posted",
+  "social_posted",
+  "funding_raised",
+  "investment_made",
+  "ipo_announced",
+  "ipo_stage_changed",
+  "repo_engaged",
+  "ipo_rumoured"
+]

Changed1 schema field changedSep 5, 2026

changedInput schema / properties / __requestBody / properties / checks / items / properties / type / enum

Previous value: -[
-  "job_posted",
-  "social_posted",
-  "funding_raised",
-  "investment_made",
-  "ipo_announced",
-  "ipo_stage_changed"
-]New value: +[
+  "job_posted",
+  "social_posted",
+  "funding_raised",
+  "investment_made",
+  "ipo_announced",
+  "ipo_stage_changed",
+  "repo_engaged"
+]

AddedAug 13, 2026

TDQS

C2.5/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the basic safety profile is covered. The description adds nothing beyond that profile—no note on billing of detected signals, delivery/webhook behavior, or non-idempotent repeat-creation risk—even though the schema contains rich behavioral detail the description could have surfaced.

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?

It is only two words, so there is zero waste, but there is also almost no structure to speak of and the under-specification makes the brevity a liability rather than a virtue. A slightly longer front-loaded sentence could have named the resource and its scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a high-complexity create tool with nested checks/target/webhook/schedule objects and numerous siblings, yet the description explains nothing about monitor semantics, creation prerequisites, or side effects. The rich schema partly compensates, but for a create operation the description is too thin.

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 nested schema already documents checks, targets, webhook, and schedule semantics. The description mentions no parameters at all, so the baseline 3 is appropriate; it neither helps nor harms.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a verb and resource ("Create a monitor") but is essentially a restatement of the tool name and gives no sense of what a monitor is, what it watches, or how it differs from siblings like monitors-create_action or monitors-update. It is minimally viable rather than reassuringly specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as monitors-create_action or the update/pause/resume siblings. The agent gets no routing signal at all.

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

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

Resources

Need Help?