Skip to main content
Glama
Keesan12

MartinLoop — Stop Runaway Loops, Bad Code & Token Waste

martin_arcade_status

Read-onlyIdempotent

Read the read-only Arcade evidence projection for a MartinLoop run: pass loopId for one exact run or omit it to load the latest persisted run.

Instructions

Read the read-only evidence projection used by the Arcade view. Provide loopId for one exact run or omit it to load the latest run. Use only for Arcade rendering; use martin_status for budget pressure or martin_run_dossier for full evidence. This tool reads persisted evidence and never changes run state.

Input Schema

NameRequiredDescriptionDefault
loopIdNoOptional MartinLoop run identifier. Omit it to read the latest persisted run.

Output Schema

NameRequiredDescriptionDefault
costYes
budgetYes
loopIdYesRun identifier represented by this Arcade snapshot.
attemptsYesNumber of recorded attempts.
warningsYesEvidence or interpretation warnings for the Arcade view.
completedYesWhether the run is outside an active lifecycle state.
verificationYesPersisted verifier evidence summary.
displayOutcomeYesTerminal verified-handoff outcome, or null while the run is active.
lifecycleStateYesCurrent persisted lifecycle state.
receiptIntegrityYesPersisted receipt-integrity verdict.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.6
    • changedOutput schema / properties / displayOutcome / anyOf
      Previous value: -[
      -  {
      -    "enum": [
      -      "VERIFIED",
      -      "STOPPED",
      -      "NEEDS REVIEW"
      -    ],
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "VERIFIED",
      +      "STOPPED",
      +      "NEEDS_REVIEW"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  2. Changed2 schema fields changedv0.5.9
    • addedInput schema / properties / loopId / description
      Added value: +"Optional MartinLoop run identifier. Omit it to read the latest persisted run."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "attempts": {
      +      "description": "Number of recorded attempts.",
      +      "minimum": 0,
      +      "type": "integer"
      +    },
      +    "budget": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "maxUsd": {
      +          "type": "number"
      +        },
      +        "remainingUsd": {
      +          "type": "number"
      +        }
      +      },
      +      "required": [
      +        "maxUsd",
      +        "remainingUsd"
      +      ],
      +      "type": "object"
      +    },
      +    "completed": {
      +      "description": "Whether the run is outside an active lifecycle state.",
      +      "type": "boolean"
      +    },
      +    "cost": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "actualUsd": {
      +          "type": "number"
      +        },
      +        "provenance": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "actualUsd",
      +        "provenance"
      +      ],
      +      "type": "object"
      +    },
      +    "displayOutcome": {
      +      "anyOf": [
      +        {
      +          "enum": [
      +            "VERIFIED",
      +            "STOPPED",
      +            "NEEDS REVIEW"
      +          ],
      +          "type": "string"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "description": "Terminal verified-handoff outcome, or null while the run is active."
      +    },
      +    "lifecycleState": {
      +      "description": "Current persisted lifecycle state.",
      +      "type": "string"
      +    },
      +    "loopId": {
      +      "description": "Run identifier represented by this Arcade snapshot.",
      +      "type": "string"
      +    },
      +    "receiptIntegrity": {
      +      "additionalProperties": true,
      +      "description": "Persisted receipt-integrity verdict.",
      +      "type": "object"
      +    },
      +    "verification": {
      +      "additionalProperties": true,
      +      "description": "Persisted verifier evidence summary.",
      +      "type": "object"
      +    },
      +    "warnings": {
      +      "description": "Evidence or interpretation warnings for the Arcade view.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "loopId",
      +    "lifecycleState",
      +    "completed",
      +    "displayOutcome",
      +    "verification",
      +    "receiptIntegrity",
      +    "attempts",
      +    "cost",
      +    "budget",
      +    "warnings"
      +  ],
      +  "type": "object"
      +}
  3. Addedv0.5.5

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is largely covered. The description reinforces this with 'reads persisted evidence and never changes run state' and notes the Arcade-only rendering purpose, but adds little beyond what the structured fields already provide.

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?

Three short sentences, front-loaded with the tool's identity and scope, with zero filler. The final clause about not changing run state slightly restates the readOnlyHint annotation, a minor redundancy.

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?

An output schema exists so return values need no explanation, and the description fully covers purpose, scoping input, alternatives, and read-only behavior. Complete for a single-optional-parameter read tool.

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% and the loopId description already documents omission meaning 'latest persisted run', so the description's equivalent statement is redundant. Baseline 3 is appropriate when the schema fully carries parameter meaning.

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 (read) and resource (the read-only evidence projection used by the Arcade view), and explicitly contrasts itself with sibling tools martin_status and martin_run_dossier. An agent can distinguish it from the other evidence-reading tools without opening any schema.

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 explicit when-to-use (Arcade rendering), when-not/alternatives (martin_status for budget pressure, martin_run_dossier for full evidence), and the loopId-vs-omit choice. Nothing is left to inference.

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