CueFrame

Resume

resume

Answer the checkpoint packet wait_job reported as awaiting_input (its {checkpointId} — read the packet FIRST with get_checkpoint and relay the stills + money triple to your human). ONE body.decision per gate: 'approve' (proceed; comments allowed — they record as taste without gating), 'revise' (the director revises per your body.comments [{anchor: {beatId}|{timecodeMs}, verdict: 'approve'|'revise'|'lock', note}] and/or body.edits, then RE-PRESENTS this same gate as a new packet — in-job, no new charge; the brief quote states the included revision cycles, beyond them revise is refused 402), or 'abandon' (end the run — the only terminal refusal). 'lock' freezes an element contractually: the director touching it surfaces as a lock_violation verdict on the next packet. On approve/revise the Director rehydrates its warm box and continues; then wait_job again.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "checkpointId": "<checkpointId>",
      "body": "<body>"
    },
    "name": "resume"
  }
}

Input Schema

Name	Required	Description
`body`	Yes	POST /checkpoints/:id/resume body — the A1 review grammar.
`commandId`	No	Retry identity. A call repeated with the same commandId returns the first result instead of acting twice.
`checkpointId`	Yes	checkpointId (path).

Output Schema

Name	Required	Description	Default
`ok`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed18 schema fields changedOct 28, 2026

addedInput schema / $defs

Added value: +{
+  "__schema0": {
+    "description": "The ONE verdict for this gate (GitHub review grammar). approve = proceed (comments allowed — they record as taste signal without gating); revise = the director revises per comments/edits and RE-PRESENTS this same gate (in-job, no re-meter); abandon = end the run.",
+    "enum": [
+      "approve",
+      "revise",
+      "abandon"
+    ],
+    "type": "string"
+  },
+  "__schema1": {
+    "items": {
+      "$ref": "#/$defs/__schema2"
+    },
+    "maxItems": 24,
+    "type": "array"
+  },
+  "__schema2": {
+    "additionalProperties": false,
+    "properties": {
+      "anchor": {
+        "anyOf": [
+          {
+            "$ref": "#/$defs/__schema3"
+          },
+          {
+            "$ref": "#/$defs/__schema4"
+          }
+        ],
+        "description": "What the comment is about: a plan beat (content gate) or a timecode on the artifact (layout/motion gates)."
+      },
+      "note": {
+        "maxLength": 2000,
+        "type": "string"
+      },
+      "verdict": {
+        "description": "Per-anchor verdict under the single gate decision. `lock` = contractually frozen — the director touching a locked element is a defect, surfaced as a lock_violation verdict on the next packet (the no-discard machinery).",
+        "enum": [
+          "approve",
+          "revise",
+          "lock"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "anchor",
+      "verdict"
+    ],
+    "type": "object"
+  },
+  "__schema3": {
+    "additionalProperties": false,
+    "properties": {
+      "beatId": {
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "beatId"
+    ],
+    "type": "object"
+  },
+  "__schema4": {
+    "additionalProperties": false,
+    "properties": {
+      "timecodeMs": {
+        "maximum": 9007199254740991,
+        "minimum": 0,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "timecodeMs"
+    ],
+    "type": "object"
+  },
+  "__schema5": {
+    "description": "Your edited stage artifact (the power path). With edits the re-presented packet carries exactly what you supplied; with comments alone the director re-authors scoped by them."
+  },
+  "__schema6": {
+    "maxLength": 4000,
+    "type": "string"
+  },
+  "__schema7": {
+    "maxLength": 128,
+    "minLength": 1,
+    "type": "string"
+  }
+}

addedInput schema / properties / body / properties / comments / $ref
```
Added value: +"#/$defs/__schema1"
```

removedInput schema / properties / body / properties / comments / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "anchor": {
-      "anyOf": [
-        {
-          "additionalProperties": false,
-          "properties": {
-            "beatId": {
-              "minLength": 1,
-              "type": "string"
-            }
-          },
-          "required": [
-            "beatId"
-          ],
-          "type": "object"
-        },
-        {
-          "additionalProperties": false,
-          "properties": {
-            "timecodeMs": {
-              "maximum": 9007199254740991,
-              "minimum": 0,
-              "type": "integer"
-            }
-          },
-          "required": [
-            "timecodeMs"
-          ],
-          "type": "object"
-        }
-      ],
-      "description": "What the comment is about: a plan beat (content gate) or a timecode on the artifact (layout/motion gates)."
-    },
-    "note": {
-      "maxLength": 2000,
-      "type": "string"
-    },
-    "verdict": {
-      "description": "Per-anchor verdict under the single gate decision. `lock` = contractually frozen — the director touching a locked element is a defect, surfaced as a lock_violation verdict on the next packet (the no-discard machinery).",
-      "enum": [
-        "approve",
-        "revise",
-        "lock"
-      ],
-      "type": "string"
-    }
-  },
-  "required": [
-    "anchor",
-    "verdict"
-  ],
-  "type": "object"
-}

removedInput schema / properties / body / properties / comments / maxItems
```
Removed value: -24
```
removedInput schema / properties / body / properties / comments / type
```
Removed value: -"array"
```
addedInput schema / properties / body / properties / decision / $ref
```
Added value: +"#/$defs/__schema0"
```

removedInput schema / properties / body / properties / decision / description

Removed value: -"The ONE verdict for this gate (GitHub review grammar). approve = proceed (comments allowed — they record as taste signal without gating); revise = the director revises per comments/edits and RE-PRESENTS this same gate (in-job, no re-meter); abandon = end the run."

removedInput schema / properties / body / properties / decision / enum
```
Removed value: -[
-  "approve",
-  "revise",
-  "abandon"
-]
```
removedInput schema / properties / body / properties / decision / type
```
Removed value: -"string"
```
addedInput schema / properties / body / properties / edits / $ref
```
Added value: +"#/$defs/__schema5"
```

removedInput schema / properties / body / properties / edits / description

Removed value: -"Your edited stage artifact (the power path). With edits the re-presented packet carries exactly what you supplied; with comments alone the director re-authors scoped by them."

addedInput schema / properties / body / properties / globalNote / $ref
```
Added value: +"#/$defs/__schema6"
```
removedInput schema / properties / body / properties / globalNote / maxLength
```
Removed value: -4000
```
removedInput schema / properties / body / properties / globalNote / type
```
Removed value: -"string"
```
addedInput schema / properties / commandId / $ref
```
Added value: +"#/$defs/__schema7"
```
removedInput schema / properties / commandId / maxLength
```
Removed value: -128
```
removedInput schema / properties / commandId / minLength
```
Removed value: -1
```
removedInput schema / properties / commandId / type
```
Removed value: -"string"
```

Changed1 schema field changedOct 22, 2026

addedInput schema / properties / commandId

Added value: +{
+  "description": "Retry identity. A call repeated with the same commandId returns the first result instead of acting twice.",
+  "maxLength": 128,
+  "minLength": 1,
+  "type": "string"
+}

Changed1 schema field changedOct 18, 2026
- addedInput schema / properties / body / example
```
Added value: +{
+  "decision": "approve"
+}
```
First observedOct 10, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond the annotations: revise is described as in-job re-presentation with no new charge, revision cycles beyond the brief's quote are refused with 402, abandon is the only terminal refusal, and lock surfaces later as a lock_violation verdict. The only mild tension is that annotations say destructiveHint=false while 'abandon' ends the run, but the description makes the consequence explicit so the agent is not misled.

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 essential instruction (which packet, read it first) is front-loaded, and the decision branches follow in the order an agent needs them. It is dense and parenthetical-heavy, and the lock semantics could be split out, but no sentence is filler.

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?

For a mutation tool with nested objects and an output schema, the description covers everything an agent needs before calling: prerequisite read, per-decision outcomes, cost/refusal boundaries, and the next step (wait_job). Return values are left to the output schema, which is appropriate.

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 coverage is 100% and the schema already explains decision, comments, anchor, verdict and commandId, so the description only needs to add workflow meaning. It does add real value by clarifying that approve comments are recorded as taste without gating and that edits take the 'power path' where the re-presented packet carries exactly what was supplied.

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 ('Answer the checkpoint packet wait_job reported as awaiting_input') and pins the exact object via {checkpointId}. It also distinguishes itself from the read path by ordering the agent to call get_checkpoint first, so the boundary with that sibling is unambiguous.

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 prerequisite ('read the packet FIRST with get_checkpoint and relay the stills + money triple to your human') and an explicit follow-up ('then wait_job again'). The three decision values are each given a when-to-use meaning, including the terminal case, so the agent knows which branch selects which behavior.

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

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