Skip to main content
Glama
Keesan12

MartinLoop — Stop Runaway Loops, Bad Code & Token Waste

martin_create_pr

Destructive

Create or preview a GitHub PR that includes a MartinLoop dossier body. Set execute=true to submit the pull request via gh.

Instructions

Create or preview a GitHub PR with a MartinLoop dossier body. Use execute=true to actually call gh.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
baseNo
fileNo
titleNo
formatNo
latestNo
loopIdNo
executeNo
runsDirNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesGitHub-flavoured Markdown PR body containing the run dossier.
gradeYesVerification grade assigned to the run.
scoreYesNumeric verification score from 0–100.
titleYesSuggested GitHub pull-request title.
loopIdYesMartinLoop run identifier used to generate the summary.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.6
    • removedInput schema / oneOf
      Removed value: -[
      -  {
      -    "required": [
      -      "file"
      -    ]
      -  },
      -  {
      -    "required": [
      -      "loopId"
      -    ]
      -  },
      -  {
      -    "required": [
      -      "latest"
      -    ]
      -  }
      -]
  2. Changed3 schema fields changedv0.5.6
    • changedOutput schema / additionalProperties
      Previous value: -trueNew value: +false
    • addedOutput schema / properties
      Added value: +{
      +  "body": {
      +    "description": "GitHub-flavoured Markdown PR body containing the run dossier.",
      +    "type": "string"
      +  },
      +  "grade": {
      +    "description": "Verification grade assigned to the run.",
      +    "enum": [
      +      "mergeable",
      +      "mergeable_with_review",
      +      "needs_review",
      +      "blocked",
      +      "insufficient_evidence"
      +    ],
      +    "type": "string"
      +  },
      +  "loopId": {
      +    "description": "MartinLoop run identifier used to generate the summary.",
      +    "type": "string"
      +  },
      +  "score": {
      +    "description": "Numeric verification score from 0–100.",
      +    "type": "number"
      +  },
      +  "title": {
      +    "description": "Suggested GitHub pull-request title.",
      +    "type": "string"
      +  }
      +}
    • addedOutput schema / required
      Added value: +[
      +  "loopId",
      +  "title",
      +  "body",
      +  "grade",
      +  "score"
      +]
  3. First observedv0.3.9

TDQS

A3.5/5.0
Behavior4/5

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

The description adds meaningful behavior beyond annotations by revealing that the default action is preview, and that the external gh command is only invoked when execute=true. Annotations already declare destructiveHint=true and idempotentHint=false, so the lack of extra destructiveness detail is acceptable.

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?

Two tightly written sentences deliver the core purpose first and the critical execution gate second. Every word earns its place; there is no filler or repetition.

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?

Despite a clear high-level purpose and an output schema, the tool has eight optional parameters with zero documentation and a 0% schema description coverage. An agent lacks necessary context about file/runsDir semantics, latest/loopId coupling, format effects, and what happens without execute.

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%, so the prose must compensate, but it only explains execute. The remaining parameters (base, file, title, format, latest, loopId, runsDir) are left entirely undefined in both the schema and the description, making it hard for an agent to populate them correctly.

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 names a concrete operation ('Create or preview a GitHub PR') with a specific body source ('MartinLoop dossier'). It is immediately distinguishable from siblings like martin_review_pr and martin_pr_summary because it clearly targets PR creation rather than review or summarization.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to choose this tool over alternatives among the many PR- and dossier-related siblings. The only directive is 'Use execute=true to actually call gh,' which is parameter-level execution guidance rather than a tool-selection criterion.

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