Skip to main content
Glama
Sign In
reforge-mcp

reforge-mcp

by Codewithaiyan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

generate_changelog

Write a human-readable REFORGE_CHANGES.md report from saved health history, fix logs, and pending fixes so repository cleanup state can be reviewed.

Instructions

Write REFORGE_CHANGES.md from saved health history, fixes and pending work. Use when: you need a human-readable report of state recorded during cleanup. Don't use when: you only need one raw saved state value (use read_memory instead).

Returns {success, path}, with error if the Markdown file could not be written. Reads health_history, fix_log and pending_fixes; it does not rescan, infer fixes from Git or populate those lists. Overwrites the report with a fresh UTC generation timestamp, so repeated calls are not idempotent.

Input Schema

NameRequiredDescriptionDefault
repo_pathYesExisting repository directory containing reforge-state.json and the output REFORGE_CHANGES.md; prefer an absolute path. Existing output is overwritten, and each successful call adds a fresh UTC timestamp.

Output Schema

NameRequiredDescriptionDefault
pathYes
errorNo
successYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.4.5
    • addedInput schema / properties / repo_path / description
      Added value: +"Existing repository directory containing reforge-state.json and the output REFORGE_CHANGES.md; prefer an absolute path. Existing output is overwritten, and each successful call adds a fresh UTC timestamp."
    • removedOutput schema / additionalProperties
      Removed value: -true
    • addedOutput schema / properties
      Added value: +{
+  "error": {
+    "type": "string"
+  },
+  "path": {
+    "type": "string"
+  },
+  "success": {
+    "type": "boolean"
+  }
+}
    • addedOutput schema / required
      Added value: +[
+  "success",
+  "path"
+]
  2. Addedv0.2.9

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, but the description goes further: it says the report is overwritten with a fresh UTC timestamp so repeated calls are not idempotent, that it errors when the Markdown file cannot be written, and that it only reads health_history, fix_log and pending_fixes without inferring fixes from Git. That is exactly the kind of context annotations cannot convey.

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?

Front-loaded with the artifact name, then organized into explicit 'Use when' / 'Don't use when' blocks and a short behavior paragraph. Every sentence adds a fact an agent needs (side effects, data sources, error condition); nothing is filler.

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?

For a one-parameter write tool with an output schema already declaring {success, path}, the description covers the remaining gaps: which state files are read, what is not inferred, overwrite/non-idempotency, and the failure mode. Nothing an agent needs to call this correctly is missing.

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 single repo_path parameter already documents the required state file, the overwrite behavior and the timestamp. The description adds no path-format or validation detail beyond that, so the baseline 3 is appropriate when the schema carries the parameter semantics.

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 concrete verb (write) and named artifact (REFORGE_CHANGES.md) plus the exact data sources: saved health history, fixes and pending work. An agent can distinguish it immediately from read_memory and from the scanning siblings because the description explicitly says it does not rescan.

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?

Provides both a positive trigger ('Use when: you need a human-readable report of state recorded during cleanup') and a negative one with a named alternative ('Don't use when: you only need one raw saved state value (use read_memory instead)'). The routing decision between this tool and a sibling is fully specified.

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

Deploy Server

Other Tools