Skip to main content
Glama
ralph-loop-mcp

ralph-loop-mcp

by hpractv

Ralph Loop MCP (Node + TypeScript)

This MCP server turns the repo's .ralph/ folder into a 3-phase workflow:

  • Phase 1: Create or refine plan documents under .github/plans/. Phase 1 produces plan files only.

  • Phase 2: Generate/refine specs under .ralph/specs/** and tasks in .ralph/fix_plan.md.

  • Phase 3: Iterate one task at a time with strict verification (npm run ci + npm run test:e2e).

See docs/DESIGN.md for architecture and positioning.

Phase 1 generator script

ralph.generate_phase1 bootstraps .ralph/phase1.sh and seeds .github/plans/project-plan.md when missing. The generated Phase 1 session is intentionally constrained to planning output only:

  • It writes plan documents only under .github/plans/

  • It does not create .ralph/specs/**

  • It does not create .ralph/fix_plan.md task items

  • Run directly: bash ./.ralph/phase1.sh

  • Run via MCP tool: ralph.generate_phase1

Related MCP server: Spec MCP Server

Phase 2 generator script

ralph.generate_phase2 scaffolds .ralph/phase2.sh and creates the baseline Phase 2 artifacts:

  • .ralph/specs/*.md

  • .ralph/fix_plan.md

  • .ralph/config.json

  • .ralph/logs/progress.txt

  • .ralph/logs/learnings.md

  • Run directly: bash ./.ralph/phase2.sh

  • Run via MCP tool: ralph.generate_phase2

ralph.generate_phase2 performs a lightweight schema validation of .ralph/config.json. If the file exists and is invalid, the tool reports validation errors without executing the script.

Phase 3 generator script

ralph.generate_phase3 scaffolds .ralph/phase3.sh and creates the Phase 3 prompt files. It fails with a clear error if .ralph/fix_plan.md does not yet exist. When the fix plan has fewer than five unchecked active tasks, it seeds Phase 2 planning items as checkboxes automatically.

Artifacts created:

  • .ralph/phase3.sh

  • .ralph/phase3-plan-prompt.md

  • .ralph/phase3-dev-prompt.md

  • .ralph/phase3-dev-signoff-prompt.md

  • .ralph/phase3-qa-prompt.md

  • .ralph/phase3-qa-close-prompt.md

  • .ralph/logs/phase3-feedback.md

  • Run directly: bash ./.ralph/phase3.sh

  • Run via MCP tool: ralph.generate_phase3

Prerequisites

  • Node.js 20 or later

  • npm

  • Build the package before running or testing (see Build section below)

Install

Standalone (this repo cloned directly as the package root):

npm install

Nested (package embedded under a parent monorepo, e.g. at ./mcp/ralph_loop_mcp):

npm install --prefix ./mcp/ralph_loop_mcp

Build

Standalone:

npm run build

Nested:

npm run --prefix ./mcp/ralph_loop_mcp build

Run (stdio)

Standalone:

node dist/index.js

Nested:

node ./mcp/ralph_loop_mcp/dist/index.js

VS Code MCP registration

Set cwd to the target project -- the repo whose .ralph/ folder the server will manage. This is typically the project you are actively developing, not the directory where this MCP package lives.

Example configuration for a standalone clone (open the target project folder in VS Code so ${workspaceFolder} resolves to it):

{
  "mcpServers": {
    "ralph-loop": {
      "command": "node",
      "args": ["dist/index.js"],
      "cwd": "${workspaceFolder}"
    }
  }
}

Example for a nested layout where the package lives at ./mcp/ralph_loop_mcp inside the target project:

{
  "mcpServers": {
    "ralph-loop": {
      "command": "node",
      "args": ["./mcp/ralph_loop_mcp/dist/index.js"],
      "cwd": "${workspaceFolder}"
    }
  }
}

If VS Code reports ${workspaceFolder} cannot be resolved, open the repository with File -> Open Folder..., or set cwd to an absolute path pointing at the target project root.

Verification prereqs

ralph.run_verification runs npm run ci followed by npm run test:e2e on the target repo (the project under cwd). Both scripts must be defined in that repo's package.json, or the tool will reject them by design.

To extend the allowlist for additional scripts, add an allowedNpmScripts array to .ralph/config.json in the target repo:

{
  "allowedNpmScripts": ["lint", "type-check"]
}

Conventions

  • .ralph/fix_plan.md is the task source of truth.

  • Blocked tasks live under a dedicated heading: ## Blocked (or ## Blocked Tasks).

  • Phase 1 planning documents live under .github/plans/.

  • Phase 2 generator script lives at .ralph/phase2.sh and is auto-created by ralph.generate_phase2 when absent.

  • Phase 3 generator script lives at .ralph/phase3.sh and is auto-created by ralph.generate_phase3 when absent.

Dev tests

Standalone:

npm test

Nested:

npm run --prefix ./mcp/ralph_loop_mcp test

Note: Run npm run build before running tests for the first time so dist/index.js exists for integration tests.

Available Tools

18 tools
ralph.append_learningB

Append a new section to .ralph/logs/learnings.md.

Inputs: body (required), title (required).

ralph.append_progressA

Append a timestamped entry to .ralph/logs/progress.txt.

Inputs: entry (required).

ralph.block_taskC

Move an active task into the dedicated Blocked section with a short reason.

Inputs: text (required), reason (required), taskId.

ralph.generate_phase1A

Set up Phase 1: creates .ralph/phase1.sh and .ralph/phase1-prd-prompt.md, seeds a draft .github/plans/project-plan.md if missing. Run bash .ralph/phase1.sh to normalize the source plan into the canonical PRD at .ralph/prd.md via ralph.write_prd. Configure phase1.sourcePlan in .ralph/config.json (default .github/plans/project-plan.md). When the PRD is ready, run ralph.generate_phase2.

Inputs: sourcePlan.

ralph.generate_phase2A

Set up Phase 2: .ralph/phase2.sh (planning persona + worker loop), config.json with defaults, phase2-planner-prompt.md, phase2-worker-prompt.md, specs/, logs/. Phase 2 reads paths.projectPlan (default .ralph/prd.md). Ensure .ralph/prd.md exists first. Run bash .ralph/phase2.sh after setup.

Inputs: planFile.

ralph.generate_phase3A

Set up Phase 3: .ralph/phase3.sh — Plan, Dev, QA personas, Dev/QA consensus sign-off, then QA close marks tasks done. Prompt files: phase3-plan-prompt.md, phase3-dev-prompt.md, phase3-qa-prompt.md, sign-off prompts. Requires .ralph/fix_plan.md. Run bash .ralph/phase3.sh.

Inputs: no named parameters.

ralph.list_filesA

List files and directories one level deep under a repo-relative path. Use this during Phase 2 exploration to discover source files, then read them with ralph.read_file.

Inputs: directory.

ralph.next_taskA

Return the next unchecked active task from .ralph/fix_plan.md (ignores blocked tasks).

Inputs: no named parameters.

ralph.read_fileA

Read any text file inside the repo by its repo-relative path. Use this during Phase 2 to explore source code and inform spec and fix-plan authoring.

Inputs: relativePath (required).

ralph.read_stateA

Read .ralph state: config, parsed tasks, spec index, PRD tail, and log tails. Call at the start of Phase 2/3 iterations.

Inputs: no named parameters.

ralph.replace_fix_planA

Replace .ralph/fix_plan.md, optionally preserving completed items from the previous file. Phase 2/3: use preserveCompleted:true when refining. You may add <!-- ralph-defer: blocked-by: task-id — note --> on the line after a checkbox to defer work.

Inputs: content (required), preserveCompleted.

ralph.run_verificationA

Run strict verification gate: npm run ci, then npm run test:e2e (stop on first failure).

Inputs: timeoutSeconds.

ralph.set_task_statusA

Check/uncheck a task in .ralph/fix_plan.md by text or taskId. In Phase 3, only the QA-close persona should call this with checked:true after Dev agrees sign-off.

Inputs: text (required), checked (required), taskId.

ralph.unblock_taskB

Move a blocked task back into the active task list (unchecked by default).

Inputs: text (required), taskId.

ralph.upsert_specA

Write/update a spec file under .ralph/specs/**. Call this iteratively during Phase 2 as you explore source files and refine your understanding.

Inputs: content (required), relativePath (required).

ralph.write_epic_planB

Write/update the canonical .ralph/epic_plan.md file.

Inputs: content (required).

ralph.write_planA

Write or update a planning document under .github/plans/. Use for draft plans before Phase 1 PRD normalization, or auxiliary planning docs.

Inputs: content (required), relativePath (required).

ralph.write_prdA

Write or replace the canonical product requirements document at .ralph/prd.md. Used by the Phase 1 Copilot session only.

Inputs: content (required).

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.6/5.0

    Scored across 18 tools

    Disambiguation4/5

    Most tools map to a distinct file, phase, or action; the write_ family is separated by documented destinations (plans, PRD, epic, specs, fix_plan). read_state vs read_file and the multiple generate_phase tools have slight conceptual overlap, but the descriptions clearly indicate when each should be used.

    Naming Consistency4/5

    All tools share the ralph. prefix and use lowercase_snake_case with a mostly verb_noun pattern (write_plan, block_task, run_verif). Minor deviations such as next_task (lacking a verb) and write_prd (abbreviated object) keep it from being perfectly consistent.

    Tool Count4/5

    At 18 tools, the set is slightly above the ideal 3-15 range, but the multi-phase workflow (setup, planning, spec writing, task tracking, logging, verification) justifies the breadth. Each tool serves a distinct step in the ralph loop, so the count feels reasonable rather than bloated.

    Completeness4/5

    The toolset covers the full ralph loop lifecycle: phase setup, PRD/plan/spec/fix-plan authoring, task state transitions, logging, and verification. Minor gaps exist—no dedicated raw fix_plan reader and no cleanup/rollback tool—but agents can work around these via read_state and overwrite capabilities.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      Advanced task automation system that reads codebases, divides complex tasks into specific steps, and rigorously executes them with complete testing, documentation, validation and automatic correction.
      MIT
    • A
      license
      A
      quality
      D
      maintenance
      Streamlines development workflows through AI-assisted codebase analysis, comprehensive planning, task breakdown with dependencies, and automated implementation verification. Enables systematic approach to complex development tasks like framework migrations and feature implementation.
      5
      21 npm
      MIT
    • A
      license
      Not graded
      quality
      D
      maintenance
      Implements GitHub's Spec-Driven Development methodology, transforming natural language requirements into executable specifications, technical plans, and ordered task lists with contract-based validation and progress tracking.
      26 npm
      2
      MIT
    • A
      license
      A
      quality
      C
      maintenance
      Enables AI coding tools to follow a structured spec-driven development workflow with three phases: requirements, design, and tasks, ensuring approval before advancing.
      10
      MIT