Skip to main content
Glama
Keesan12

MartinLoop — Stop Runaway Loops, Bad Code & Token Waste

martin_arcade_status

Read-onlyIdempotent

Retrieve persisted evidence for Arcade rendering. Specify a loop ID for one exact run or omit it to get the latest run. Read-only; never changes run state.

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

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

Output Schema

TableJSON 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. 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"
      +}
  2. Addedv0.5.5

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds useful context by clarifying that the tool reads 'persisted evidence' and that omitting loopId dynamically loads the latest run. The closing sentence reinforces the read-only guarantee, though it is somewhat redundant with 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?

The description is four sentences with no filler. It front-loads the core purpose, then covers parameter behavior, usage boundaries, and read-only safety, with every sentence earning its place.

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?

Given a single optional parameter, an output schema, and annotations covering safety, the description is complete. It provides purpose, usage constraints, alternatives, parameter guidance, and state-change guarantees, so an agent can select and invoke the tool correctly.

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 the schema already documents loopId as optional with the 'omit to read latest run' behavior. The description restates this logic but adds no new semantic detail beyond the input schema.

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 uses a specific verb ('Read'), names a precise resource ('read-only evidence projection used by the Arcade view'), and explicitly distinguishes itself from sibling tools like martin_status and martin_run_dossier. An agent can immediately understand what this tool does and how it differs from alternatives.

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?

The description states 'Use only for Arcade rendering' and explicitly redirects to martin_status for budget pressure and martin_run_dossier for full evidence. It also explains the loopId behavior clearly: provide it for an exact run or omit it for the latest run.

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