MartinLoop — Stop Runaway Loops, Bad Code & Token Waste

martin_run

Destructive

Run approved coding tasks under strict budget, token, and verification controls to stop runaway loops, bad code, and token waste.

Instructions

Execute a governed MartinLoop coding run after MCP workflow admission is satisfied. Use when the user has authorized implementation, bug fixing, tests, or refactoring and doctor/estimate/plan/preflight receipts match this task. Do not use for question-only diagnosis or when policy, budget, credentials, or scope still need consent. Next: read martin_dossier and verifier evidence.

Input Schema

TableJSON Schema

Name	Required	Description
`model`	No	Optional model override passed to the CLI.
`engine`	No	Which agent CLI to use. Defaults to claude.
`maxUsd`	No	Hard budget ceiling in USD.
`maxTokens`	No	Maximum total tokens across all attempts.
`objective`	Yes	The coding task to complete. Be specific about what needs to change.
`projectId`	No	Project identifier for telemetry.
`deniedPaths`	No	Repo-relative path globs Martin must never modify.
`workspaceId`	No	Workspace identifier for telemetry.
`allowedPaths`	No	Repo-relative path globs Martin may modify.
`maxIterations`	No	Maximum number of loop attempts.
`verifyTimeoutMs`	No	Hard timeout for each verifier command in milliseconds.
`verificationPlan`	No	Commands that must all exit 0 for the task to be considered complete.
`workingDirectory`	No	Optional repo-root override resolved under the MCP workspace root. Must stay within that safe root.
`providerExecutionTimeoutMs`	No	Hard timeout for each provider coding process in milliseconds.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`budget`	Yes
`engine`	Yes
`loopId`	Yes
`reason`	Yes
`status`	Yes
`costUsd`	Yes
`attempts`	Yes
`pressure`	Yes
`inspection`	Yes
`shouldStop`	Yes
`lifecycleState`	Yes
`remainingTokens`	No
`workingDirectory`	Yes
`remainingBudgetUsd`	Yes
`verificationPassed`	Yes
`remainingIterations`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.6.5Sep 19, 2026
- addedOutput schema / properties / inspection / properties / loop / properties / activeAttemptId
```
Added value: +{
+  "description": "ID of the currently active attempt, when a run is in progress.",
+  "type": "string"
+}
```

Changed3 schema fields changedv0.5.6Aug 30, 2026

changedOutput schema / properties / budget / required

Previous value: -[
-  "maxUsd",
-  "softLimitUsd",
-  "maxIterations",
-  "maxTokens"
-]New value: +[
+  "maxUsd",
+  "softLimitUsd",
+  "maxIterations"
+]

changedOutput schema / properties / inspection / properties / loop / required

Previous value: -[
-  "loopId",
-  "title",
-  "objective",
-  "status",
-  "lifecycleState",
-  "attempts",
-  "costUsd",
-  "avoidedUsd",
-  "pressure",
-  "shouldStop",
-  "remainingBudgetUsd",
-  "remainingIterations",
-  "remainingTokens"
-]New value: +[
+  "loopId",
+  "title",
+  "objective",
+  "status",
+  "lifecycleState",
+  "attempts",
+  "costUsd",
+  "avoidedUsd",
+  "pressure",
+  "shouldStop",
+  "remainingBudgetUsd",
+  "remainingIterations"
+]

changedOutput schema / required

Previous value: -[
-  "status",
-  "lifecycleState",
-  "reason",
-  "attempts",
-  "costUsd",
-  "verificationPassed",
-  "loopId",
-  "pressure",
-  "shouldStop",
-  "remainingBudgetUsd",
-  "remainingIterations",
-  "remainingTokens",
-  "engine",
-  "workingDirectory",
-  "budget",
-  "inspection"
-]New value: +[
+  "status",
+  "lifecycleState",
+  "reason",
+  "attempts",
+  "costUsd",
+  "verificationPassed",
+  "loopId",
+  "pressure",
+  "shouldStop",
+  "remainingBudgetUsd",
+  "remainingIterations",
+  "engine",
+  "workingDirectory",
+  "budget",
+  "inspection"
+]

Changed4 schema fields changedv0.5.5Aug 23, 2026

removedOutput schema / properties / costProvenance

Removed value: -{
-  "enum": [
-    "actual",
-    "calculated",
-    "estimated",
-    "unavailable"
-  ],
-  "type": "string"
-}

removedOutput schema / properties / inspection / properties / loop / properties / costProvenance

Removed value: -{
-  "enum": [
-    "actual",
-    "calculated",
-    "estimated",
-    "unavailable"
-  ],
-  "type": "string"
-}

changedOutput schema / properties / inspection / properties / loop / required

Previous value: -[
-  "loopId",
-  "title",
-  "objective",
-  "status",
-  "lifecycleState",
-  "attempts",
-  "costUsd",
-  "costProvenance",
-  "avoidedUsd",
-  "pressure",
-  "shouldStop",
-  "remainingBudgetUsd",
-  "remainingIterations",
-  "remainingTokens"
-]New value: +[
+  "loopId",
+  "title",
+  "objective",
+  "status",
+  "lifecycleState",
+  "attempts",
+  "costUsd",
+  "avoidedUsd",
+  "pressure",
+  "shouldStop",
+  "remainingBudgetUsd",
+  "remainingIterations",
+  "remainingTokens"
+]

changedOutput schema / required

Previous value: -[
-  "status",
-  "lifecycleState",
-  "reason",
-  "attempts",
-  "costUsd",
-  "costProvenance",
-  "verificationPassed",
-  "loopId",
-  "pressure",
-  "shouldStop",
-  "remainingBudgetUsd",
-  "remainingIterations",
-  "remainingTokens",
-  "engine",
-  "workingDirectory",
-  "budget",
-  "inspection"
-]New value: +[
+  "status",
+  "lifecycleState",
+  "reason",
+  "attempts",
+  "costUsd",
+  "verificationPassed",
+  "loopId",
+  "pressure",
+  "shouldStop",
+  "remainingBudgetUsd",
+  "remainingIterations",
+  "remainingTokens",
+  "engine",
+  "workingDirectory",
+  "budget",
+  "inspection"
+]

Changed2 schema fields changedv0.5.4Aug 22, 2026

addedInput schema / properties / providerExecutionTimeoutMs

Added value: +{
+  "description": "Hard timeout for each provider coding process in milliseconds.",
+  "exclusiveMinimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / verifyTimeoutMs

Added value: +{
+  "description": "Hard timeout for each verifier command in milliseconds.",
+  "exclusiveMinimum": 0,
+  "type": "integer"
+}

Changed4 schema fields changedv0.5.3Aug 19, 2026

addedOutput schema / properties / costProvenance

Added value: +{
+  "enum": [
+    "actual",
+    "calculated",
+    "estimated",
+    "unavailable"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / inspection / properties / loop / properties / costProvenance

Added value: +{
+  "enum": [
+    "actual",
+    "calculated",
+    "estimated",
+    "unavailable"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / inspection / properties / loop / required

Previous value: -[
-  "loopId",
-  "title",
-  "objective",
-  "status",
-  "lifecycleState",
-  "attempts",
-  "costUsd",
-  "avoidedUsd",
-  "pressure",
-  "shouldStop",
-  "remainingBudgetUsd",
-  "remainingIterations",
-  "remainingTokens"
-]New value: +[
+  "loopId",
+  "title",
+  "objective",
+  "status",
+  "lifecycleState",
+  "attempts",
+  "costUsd",
+  "costProvenance",
+  "avoidedUsd",
+  "pressure",
+  "shouldStop",
+  "remainingBudgetUsd",
+  "remainingIterations",
+  "remainingTokens"
+]

changedOutput schema / required

Previous value: -[
-  "status",
-  "lifecycleState",
-  "reason",
-  "attempts",
-  "costUsd",
-  "verificationPassed",
-  "loopId",
-  "pressure",
-  "shouldStop",
-  "remainingBudgetUsd",
-  "remainingIterations",
-  "remainingTokens",
-  "engine",
-  "workingDirectory",
-  "budget",
-  "inspection"
-]New value: +[
+  "status",
+  "lifecycleState",
+  "reason",
+  "attempts",
+  "costUsd",
+  "costProvenance",
+  "verificationPassed",
+  "loopId",
+  "pressure",
+  "shouldStop",
+  "remainingBudgetUsd",
+  "remainingIterations",
+  "remainingTokens",
+  "engine",
+  "workingDirectory",
+  "budget",
+  "inspection"
+]

First observedv0.3.9Jul 29, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, openWorldHint=false, idempotentHint=false. The description adds context about governance and prerequisites ('governed', 'after MCP workflow admission is satisfied') but does not disclose additional behavioral traits such as file modification scope, side effects, or failure modes beyond what annotations imply. It neither contradicts nor enriches beyond the annotations significantly, so a 3 is appropriate.

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?

The description is three sentences, front-loaded with the purpose, then usage conditions, then next steps. Every sentence earns its place; there is no redundancy or filler. It is concise and well-structured.

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?

Given the 14-parameter schema (fully documented) and presence of an output schema, the description covers the essential operational context: when to invoke, prerequisites, and next steps. It lacks explicit detail on the execution behavior (e.g., that it modifies files and runs verification), but this is implied by 'coding run' and the verificationPlan parameter. Minor gap, so 4.

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 100%, so all 14 parameters are fully documented in the input schema. The description does not add any parameter-specific meaning or clarify usage of individual parameters. Since the schema carries the full load, the description adds no value here, justifying the baseline score of 3.

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?

The description clearly states the action ('Execute a governed MartinLoop coding run') and the resource (MartinLoop coding run). It specifies the verb and resource, and the context of 'after MCP workflow admission is satisfied' adds specificity. It differentiates from question-only diagnosis, though it doesn't name specific sibling tools. This is clear and near-excellent, but lacking explicit sibling distinction.

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?

Explicitly states when to use: 'when the user has authorized implementation, bug fixing, tests, or refactoring and doctor/estimate/plan/preflight receipts match this task.' And when not to use: 'Do not use for question-only diagnosis or when policy, budget, credentials, or scope still need consent.' Also provides next steps. This is exemplary usage guidance.

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

martin_run

Instructions

Input Schema

Output Schema

Schema Changelog

TDQS

Other Tools