Duvo MCP

Bulk Update Case Status

bulkUpdateCaseStatus

Destructive

Update the status of multiple cases to pending, completed, failed, or canceled. Interrupts any active runs and releases their case ownership, but never cancels their human-in-the-loop state — pending requests and open approval batches stay answerable/resolvable from the run view. Settling a case archives the pending requests on every run attached to it, both the runs this call interrupted and any that were already terminal, so they leave the activity inbox instead of outliving the case there. Resetting to pending archives nothing and re-dispatches cases to the queue's trigger consumer.

Input Schema

Name	Required	Description
`search`	No	Free-text search selecting the cases when all_matching is true.
`status`	Yes	Target status for each case. `completed`, `failed`, and `canceled` are terminal — `canceled` records a deliberate human stop, distinct from a system `failed`. `pending` resets the case (the queue's trigger consumer, if any, will re-claim it). `success` is not settable: it means an evaluation passed.
`filters`	No	Filters selecting the cases when all_matching is true.
`case_ids`	No	Explicit case IDs to act on (1-100). Provide this or set all_matching.
`queue_id`	Yes	The queue's unique identifier
`all_matching`	No	When true, act on every case matching the provided filters/search instead of an explicit id list.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 12, 2026

addedInput schema / properties / filters / properties / completed_at_from

Added value: +{
+  "description": "Keep Cases that reached an outcome at or after this time (inclusive). An ISO timestamp or a lookback such as `7d` or `12h`.",
+  "type": "string"
+}

addedInput schema / properties / filters / properties / completed_at_to

Added value: +{
+  "description": "Keep Cases that reached an outcome before this time (exclusive). An ISO timestamp or a lookback such as `7d` or `12h`.",
+  "type": "string"
+}

addedInput schema / properties / filters / properties / failure_source

Added value: +{
+  "description": "Keep only failed Cases, by who failed them: `system` when Duvo could not finish the Case, `manual` when a person marked it failed.",
+  "items": {
+    "enum": [
+      "system",
+      "manual"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

Changed1 schema field changedSep 14, 2026
- addedInput schema / properties / filters / properties / awaiting_my_approval
```
Added value: +{
+  "type": "boolean"
+}
```

Changed3 schema fields changedSep 8, 2026

addedInput schema / properties / filters / properties / created_at_to
```
Added value: +{
+  "type": "string"
+}
```

addedInput schema / properties / filters / properties / json_data

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "operator": {
+        "enum": [
+          "equals",
+          "notEquals",
+          "in",
+          "notIn",
+          "gt",
+          "gte",
+          "lt",
+          "lte",
+          "contains",
+          "isSet",
+          "isNotSet"
+        ],
+        "type": "string"
+      },
+      "path": {
+        "pattern": "^\\$(\\.[A-Za-z_][A-Za-z0-9_]{0,63})+$",
+        "type": "string"
+      },
+      "value": {
+        "anyOf": [
+          {
+            "anyOf": [
+              {
+                "type": "string"
+              },
+              {
+                "type": "number"
+              },
+              {
+                "type": "boolean"
+              }
+            ]
+          },
+          {
+            "items": {
+              "anyOf": [
+                {
+                  "type": "string"
+                },
+                {
+                  "type": "number"
+                },
+                {
+                  "type": "boolean"
+                }
+              ]
+            },
+            "maxItems": 100,
+            "minItems": 1,
+            "type": "array"
+          }
+        ]
+      }
+    },
+    "required": [
+      "path",
+      "operator"
+    ],
+    "type": "object"
+  },
+  "maxItems": 12,
+  "type": "array"
+}

addedInput schema / properties / filters / properties / updated_at_to
```
Added value: +{
+  "type": "string"
+}
```

Changed2 schema fields changedAug 19, 2026

changedInput schema / properties / status / description

Previous value: -"Target status for each case. `completed` and `failed` are terminal; `pending` resets the case (the queue's trigger consumer, if any, will re-claim it)."New value: +"Target status for each case. `completed`, `failed`, and `canceled` are terminal — `canceled` records a deliberate human stop, distinct from a system `failed`. `pending` resets the case (the queue's trigger consumer, if any, will re-claim it). `success` is not settable: it means an evaluation passed."

changedInput schema / properties / status / enum

Previous value: -[
-  "pending",
-  "completed",
-  "failed"
-]New value: +[
+  "pending",
+  "completed",
+  "failed",
+  "canceled"
+]

Changed1 schema field changedAug 18, 2026

addedInput schema / properties / filters / properties / issue_severity

Added value: +{
+  "items": {
+    "enum": [
+      "critical",
+      "medium"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

First observedAug 17, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=false), the description discloses concrete side effects an agent must know before calling: it interrupts active runs and releases case ownership, deliberately preserves human-in-the-loop state so pending requests remain answerable, archives pending requests across all attached runs when settling, and archives nothing when resetting to pending. This is exactly the kind of irreversible-consequence detail a destructive bulk tool needs.

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

Conciseness4/5

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

The core action is front-loaded in the first sentence, and the subsequent sentences each cover a distinct consequence (run interruption, human-in-the-loop preservation, archival on settle vs reset). It is dense and longer than average, but every clause carries operational weight for a destructive bulk mutation.

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?

With no output schema and a destructive bulk operation, the description covers the critical blast-radius details (run interruption, ownership release, archival scope, re-dispatch on reset). It omits only secondary concerns such as permission requirements and partial-failure behavior, which keeps it short of a 5.

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%, so the schema already documents all six parameters including the status enum and its reset semantics. The description's mention of the four settable statuses and the reset behavior largely restates what the schema already carries, so it adds little parameter-level meaning beyond 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?

The description states a specific verb+resource+scope: 'Update the status of multiple cases to pending, completed, failed, or canceled.' The bulk scope and the enumeration of target statuses let an agent distinguish it from single-case updateCase and from bulkUpdateCasePriority or bulkReprocessCases without opening a schema.

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

Usage Guidelines3/5

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

Usage is implied by 'multiple cases' (use when acting on many at once, rather than the single-case sibling), but the description never explicitly says when to prefer this over updateCase or the other bulk siblings. It gives no exclusions or prerequisites, so routing relies on inference.

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

All Duvo 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?