MartinLoop — Stop Runaway Loops, Bad Code & Token Waste

martin_continue

Destructive

Record a durable continue or resume request after a human pause or approval checkpoint so a Martin run can resume under governance.

Instructions

Record a durable continue or resume request for a Martin run after a human pause or approval checkpoint.

Input Schema

Name	Required	Description	Default
`file`	No
`latest`	No
`loopId`	No
`reason`	No
`runsDir`	No
`requestedBy`	No

Output Schema

Name	Required	Description
`ok`	Yes	Whether the control receipt was recorded.
`state`	Yes	Run control state after this request, including all recorded receipts.
`action`	Yes	The control action that was recorded.
`loopId`	Yes	MartinLoop run identifier the control was applied to.
`reason`	No	Human-readable reason for the control, if provided.
`summary`	Yes	Human-readable result of the control request.
`controlId`	Yes	Unique receipt ID for this control action.
`requestedAt`	Yes	ISO 8601 timestamp when the control was recorded.
`requestedBy`	No	Identity that requested the control, if provided.
`requestedAction`	Yes	The control action that was requested.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.8.6Oct 16, 2026

addedOutput schema / properties / ok

Added value: +{
+  "description": "Whether the control receipt was recorded.",
+  "type": "boolean"
+}

addedOutput schema / properties / requestedAction

Added value: +{
+  "description": "The control action that was requested.",
+  "enum": [
+    "pause",
+    "cancel",
+    "continue"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / state

Added value: +{
+  "additionalProperties": true,
+  "description": "Run control state after this request, including all recorded receipts.",
+  "type": "object"
+}

addedOutput schema / properties / summary

Added value: +{
+  "description": "Human-readable result of the control request.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "loopId",
-  "action",
-  "controlId",
-  "requestedAt"
-]New value: +[
+  "loopId",
+  "action",
+  "controlId",
+  "requestedAt",
+  "ok",
+  "summary",
+  "requestedAction",
+  "state"
+]

Changed1 schema field changedv0.6.6Sep 23, 2026

removedInput schema / oneOf

Removed value: -[
-  {
-    "required": [
-      "file"
-    ]
-  },
-  {
-    "required": [
-      "loopId"
-    ]
-  },
-  {
-    "required": [
-      "latest"
-    ]
-  }
-]

Changed3 schema fields changedv0.5.6Aug 30, 2026

changedOutput schema / additionalProperties
```
Previous value: -trueNew value: +false
```

addedOutput schema / properties

Added value: +{
+  "action": {
+    "description": "The control action that was recorded.",
+    "enum": [
+      "pause",
+      "cancel",
+      "continue"
+    ],
+    "type": "string"
+  },
+  "controlId": {
+    "description": "Unique receipt ID for this control action.",
+    "type": "string"
+  },
+  "loopId": {
+    "description": "MartinLoop run identifier the control was applied to.",
+    "type": "string"
+  },
+  "reason": {
+    "description": "Human-readable reason for the control, if provided.",
+    "type": "string"
+  },
+  "requestedAt": {
+    "description": "ISO 8601 timestamp when the control was recorded.",
+    "type": "string"
+  },
+  "requestedBy": {
+    "description": "Identity that requested the control, if provided.",
+    "type": "string"
+  }
+}

addedOutput schema / required

Added value: +[
+  "loopId",
+  "action",
+  "controlId",
+  "requestedAt"
+]

First observedv0.3.9Jul 29, 2026

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already disclose destructiveHint=true and idempotentHint=false, so the safety profile is carried by structured data. The description adds useful context ('durable' request, triggered by a pause/approval checkpoint) but never explains what state is mutated, whether the request can be rejected, or what permissions are required, leaving a non-trivial gap for a destructive write.

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?

A single front-loaded sentence with no filler, and the trigger condition is placed after the core action. Efficient, though its brevity contributes to the gaps in the other dimensions.

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?

An output schema exists, so return values need not be described. Nevertheless, for a six-parameter destructive, non-idempotent write tool, the description omits all parameter guidance and any detail on what the durable request does or how it is consumed, leaving it under-specified for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across six parameters (file, latest, loopId, reason, runsDir, requestedBy), so the description is the only place meaning could be added. It explains none of them, not even the const-true 'latest' flag or the purpose of 'reason'/'requestedBy', offering only a faint framing that this is a 'request' object.

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

Purpose4/5

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

States a specific verb ('Record') and resource ('continue or resume request for a Martin run'), and the clause 'after a human pause or approval checkpoint' clarifies the state it acts on. It does not explicitly name or distinguish itself from nearby siblings such as martin_pause or martin_cancel, so it stops short of a 5.

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?

The description implies the usage context ('after a human pause or approval checkpoint'), which is genuine situational guidance. However, it names no alternative and gives no when-not condition, so the agent must infer the boundary against martin_pause, martin_cancel, and martin_run.

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