MartinLoop — Stop Runaway Loops, Bad Code & Token Waste

martin_triage_runs

Read-onlyIdempotent

Prioritize saved runs that failed or were interrupted to decide what to fix next. Focuses on attention-worthy attempts, enabling quick review before retrying.

Instructions

Read-only prioritization of saved Martin runs that need attention. Use when the user says a prior attempt failed, asks what to fix next, or resumes an interrupted session. Do not use for a brand-new objective with no relevant run history. Next: inspect the selected run or dossier before retrying.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum number of runs to triage. Defaults to 20.
`model`	No	Filter by attempt model.
`status`	No	Filter by loop status.
`runsDir`	No	Optional runs-root override.
`adapterId`	No	Filter by attempt adapter ID.
`updatedAfter`	No	Optional ISO-8601 timestamp for recency filtering.
`includeHealthy`	No	When true, include healthy runs instead of only attention-worthy findings.
`lifecycleState`	No	Filter by lifecycle state.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`source`	Yes
`filters`	Yes
`findings`	Yes
`runsRoot`	Yes
`warnings`	Yes
`findingCount`	Yes
`evaluatedRuns`	Yes
`severityBreakdown`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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

Changed1 schema field changedv0.5.6Aug 30, 2026

changedOutput schema / properties / findings / items / 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"
+]

Changed2 schema fields changedv0.5.5Aug 23, 2026

removedOutput schema / properties / findings / items / properties / loop / properties / costProvenance

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

changedOutput schema / properties / findings / items / 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"
+]

Changed2 schema fields changedv0.5.3Aug 19, 2026

addedOutput schema / properties / findings / items / properties / loop / properties / costProvenance

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

changedOutput schema / properties / findings / items / 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"
+]

First observedv0.3.9Jul 29, 2026

TDQS

A4.5/5.0

Behavior4/5

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

The description labels the operation 'read-only', which aligns with readOnlyHint and idempotentHint, and adds non-obvious selection behavior by saying only runs 'that need attention' are prioritized. It also provides the workflow cue to inspect the selected run or dossier before retrying, which is useful context beyond the annotations.

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?

Three short sentences cover purpose, usage triggers, and next step with no filler. The key selection signal, that this is for attention-worthy runs and not brand-new objectives, is front-loaded.

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?

With readOnly and idempotent annotations, a fully described 8-parameter schema, and an output schema present, the description supplies what structured fields cannot: selection rationale and follow-up workflow. It is complete enough for an agent to decide when to invoke and what to do next.

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% and each parameter has a meaningful description, including default behavior for limit and the includeHealthy filter. The tool description itself adds no parameter-level detail, which is acceptable given the high-coverage 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 resource ('saved Martin runs'), the action ('prioritization'), and the filtering criterion ('that need attention'). This clearly positions it against siblings like martin_list_runs or martin_status, which imply plain listing or status checks rather than attention-based triage.

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?

It gives concrete positive triggers ('prior attempt failed', 'asks what to fix next', 'resumes an interrupted session') and an explicit exclusion ('Do not use for a brand-new objective with no relevant run history'). It also names the next action, so an agent knows both when to call and what to do afterward.

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

martin_triage_runs

Instructions

Input Schema

Output Schema

Schema Changelog

TDQS

Other Tools