Manifold MCP

Update a monitor

monitoring_update_monitor

Pauses, resumes, renames, describes or reschedules a monitor, changes what it checks, or runs a check now.

Use when: "pause the Reddit monitor", "check daily instead", "run it now", "call it Rivals", "add r/startups to it", or a monitor paused for credits after the user added more. Not for: changing its preset; create a new monitor. Deleting, use monitoring_delete_monitor. Returns: Record. monitor, as monitoring_get_monitors returns it. New fields replace all the old ones; the next check runs within five minutes as a new starting point and reports no changes. Cost: 0 credits. A check run now charges its calls as a scheduled one would. Example: {"monitor_id": "trk_01J...", "status": "paused"}

Input Schema

Name	Required	Description
`name`	No
`fields`	No	All of the preset's fields, as monitoring_create_monitor takes them. The next check is a new starting point.
`status`	No	paused stops its checks; active resumes them.
`cadence`	No
`run_now`	No	Run a check within five minutes.
`monitor_id`	Yes	From monitoring_get_monitors.
`description`	No	Replaces the description; empty puts back the line made from the fields.

Output Schema

Name	Required	Description	Default
`meta`	Yes
`error`	No
`hints`	Yes
`monitor`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 8, 2026

addedOutput schema / properties / meta / properties / monitor_offer

Added value: +{
+  "additionalProperties": false,
+  "description": "This lookup came back on another day: after the task, offer the user once a monitor that repeats it, previewing its cost first.",
+  "properties": {
+    "cadence": {
+      "type": "string"
+    },
+    "est_credits_month": {
+      "type": "number"
+    },
+    "fields": {
+      "additionalProperties": {},
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "message": {
+      "type": "string"
+    },
+    "preset": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "preset",
+    "fields",
+    "cadence",
+    "est_credits_month",
+    "message"
+  ],
+  "type": "object"
+}

Changed1 schema field changedNov 7, 2026

changedOutput schema / properties / meta / properties / credits_remaining / description

Previous value: -"The workspace's credits left after this call. null when the call did not check the balance (free tools, cache hits, dry runs, tasks) or the balance has no limit."New value: +"The workspace's credits left after this call. null when the call did not check the balance (free tools, cache hits, dry runs, tasks) or the balance has no limit. Leaves out credits held for calls still running, so it can dip during parallel calls and come back; credits_charged is what this call cost."

Changed1 schema field changedNov 1, 2026

addedOutput schema / properties / meta / properties / feedback_request

Added value: +{
+  "additionalProperties": false,
+  "description": "Once per workspace: after the task, ask the user once for feedback and send any answer with submit_feedback.",
+  "properties": {
+    "message": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "message"
+  ],
+  "type": "object"
+}

AddedOct 30, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare the safety profile (readOnly false, destructive false, idempotent false). The description adds useful behavior beyond that: fields are replaced wholesale, the next check starts fresh within five minutes with no reported changes, and run_now charges calls like a scheduled check while the update itself is free. It still does not explain what happens when multiple update parameters are combined in one call (e.g., status plus run_now), which is the main remaining behavioral unknown.

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 verb list, then labeled Use when / Not for / Returns / Cost / Example sections. Every sentence carries information an agent would otherwise have to infer; nothing is padding.

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?

Covers purpose, routing, side effects, cost, timing, and a concrete call example, which is strong for a 7-parameter mutation tool with an output schema. The gap is interaction between simultaneous parameters and the absence of guidance on the nested 'fields' object beyond noting it replaces the preset fields.

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 coverage is 71% and the schema already explains status, description, fields, and run_now semantics; the description mostly restates these (wholesale replacement, immediate check) rather than adding new per-parameter meaning. It does clarify cost implications of run_now and that a rescheduled check restarts the baseline, but parameters like cadence and name receive no added guidance in the description.

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?

Opening sentence names the resource (a monitor) and enumerates specific operations: pause, resume, rename, describe, reschedule, change fields, run now. This is far more specific than the title and lets an agent map an intent like 'check daily instead' to this 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?

Provides an explicit 'Use when' block with concrete user phrasings, including the non-obvious case of a monitor paused for credits. The 'Not for' block routes preset changes to monitoring_create_monitor and deletion to monitoring_delete_monitor, leaving no ambiguity against the monitoring siblings.

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

All Manifold MCP 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?