Skip to content
/
Tier A A10 Memory engine

cline-mcp-memory-bank (dazeb)

cline-mcp-memory-bank · dazeb/cline-mcp-memory-bank · ★ 60 · last commit 2025-07-17

Provides four structured Markdown files (projectContext, activeContext, progress, decisionLog) managed via an MCP server so Cline retains project context between sessions.

Best whenFour fixed Markdown file categories are sufficient for AI coding agent memory; no database or graph structure is needed.
Skip ifRequiring database infrastructure for memory, Complex setup for basic continuity
vs seeds
ccmemory's Neo4j graph + vector indexes. No lifecyc…
Primitive shape 4 total
MCP tools 4
00

Summary

cline-mcp-memory-bank — Summary

cline-mcp-memory-bank is an MCP server that provides persistent project context management for Cline (VSCode extension), storing memory across sessions in four structured Markdown files within a memory-bank/ folder. It solves the session-reset problem for Cline users: each new conversation starts from zero unless the AI explicitly reads the memory bank files. The server exposes four tools (initialize_memory_bank, update_context, record_decision, track_progress) plus four MCP resources (projectContext.md, activeContext.md, progress.md, decisionLog.md) — one tool and one resource per memory dimension. It targets Cline exclusively (relies on Cline's MCP settings file) and ships no hooks, no lifecycle events, no agent instructions; all state management is manual (user asks Cline to run MCP tools). The project is in active development (last push 2025-07), MIT-unlicensed, 60 stars. Compared to seeds, it is closest to ccmemory but without graph structure, vector search, or lifecycle automation — it is the simplest possible "file-based MCP bridge" variant, where the MCP layer is purely a file-writer rather than a knowledge store.

01

Overview

cline-mcp-memory-bank — Overview

Origin

Created by dazeb (GitHub user), inspired by roo-code-memory-bank by GreatScottyMac. Published in early 2025 as a practical companion for Cline VSCode extension users who experienced the "cold start" problem with AI-assisted development.

Philosophy

The README describes the core promise as "giving your AI assistant a memory that doesn't forget what you've been working on, even when you close VSCode and come back later." The design philosophy is extremely simple: structured Markdown is sufficient for persistent memory; no database is needed. The memory bank is explicitly conceptualized as an organized folder of files that the AI reads, not a queryable knowledge store.

Key Manifesto Quotes

From the README system prompt suggestion:

NEVER proceed without checking memory bank context
ALWAYS maintain consistent project state
Record ALL significant technical decisions
Track progress in real-time
Keep context updated with EVERY change

Target Use Case

Long-running projects in Cline (VSCode extension) where a developer needs:

  • Continuity across sessions without re-explaining project context
  • A structured log of decisions and progress
  • Team awareness of what has been built and why

Notable Design Choices

  • No lifecycle hooks — memory updates require explicit user prompting
  • Four fixed files (projectContext.md, activeContext.md, progress.md, decisionLog.md) rather than flexible schema
  • The MCP server auto-detects tech stack from package.json, requirements.txt, etc. on initialization
  • Includes an embedded system prompt template users can paste into Cline's Custom Instructions field to make Cline reference the memory bank automatically
02

Architecture

cline-mcp-memory-bank — Architecture

Distribution

Standalone repo, not on npm. Requires manual clone + build.

Install

git clone https://github.com/dazeb/cline-mcp-memory-bank
cd cline-mcp-memory-bank
pnpm install
pnpm run build
node build/index.js initialize_memory_bank .

Then manually add the server to Cline's MCP settings file:

  • Linux: ~/.config/Code - Insiders/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
  • macOS: ~/Library/Application Support/Code - Insiders/...

Directory Structure (Memory Bank output)

When initialized, creates in the project root:

memory-bank/
├── projectContext.md    # Tech stack, architecture, dependencies
├── activeContext.md     # Current session: tasks, open questions, recent updates
├── progress.md          # Phase, completed tasks, in-progress, blockers
└── decisionLog.md       # Decision history with rationale and alternatives

Required Runtime

  • Node.js v16+
  • VS Code with Cline extension (saoudrizwan.claude-dev)
  • pnpm (for development)

Target AI Tools

  • Cline VSCode Extension (primary / exclusive)

Key Classes

Single MemoryBankServer class in src/index.ts (~600 lines). Implements:

  • MCP SDK Server from @modelcontextprotocol/sdk
  • StdioServerTransport for communication
  • In-memory SessionState tracking question count, current phase, task updates
  • Platform-aware MCP settings path resolution (Linux/macOS/Windows)
  • Tech stack auto-detection from common config files

Configuration Files

None at the framework level; configuration is the Cline MCP settings JSON entry.

03

Components

cline-mcp-memory-bank — Components

MCP Tools (4)

Tool Purpose
initialize_memory_bank Creates memory-bank/ directory with four template files; auto-detects tech stack from project files
update_context Writes to activeContext.md: session date, mode, current task, session state
record_decision Appends to decisionLog.md: title, description, rationale, alternatives, status, impact
track_progress Updates progress.md: current phase, completed items, in-progress tasks, blockers

MCP Resources (4)

Resource URI File Purpose
memory://project/context projectContext.md Read project overview, tech stack, setup
memory://active/context activeContext.md Read current session state
memory://progress/log progress.md Read progress tracking
memory://decisions/log decisionLog.md Read decision history

Hooks

None. No lifecycle hooks.

Skills / Commands

None shipped. Users are expected to paste a system prompt template into Cline's Custom Instructions field (provided in README).

Scripts

None automated. The node build/index.js initialize_memory_bank . command is a one-time setup call.

Templates

The initialization tool creates four Markdown template files with structured sections. The README also provides a copy-paste system prompt for Cline custom instructions.

05

Prompts

cline-mcp-memory-bank — Prompts

System Prompt Template (from README — Cline Custom Instructions)

This is the suggested prompt to paste into Cline's Custom Instructions field. It transforms Cline into a memory-bank-aware agent:

Before working on any task:
1. Check the memory bank:
   - Read memory-bank/projectContext.md for tech stack and architecture
   - Read memory-bank/activeContext.md for current state and tasks
   - Read memory-bank/progress.md for project status
   - Review memory-bank/decisionLog.md for past decisions

After EVERY task:
1. Update active context with:
   - Task completion status
   - New information learned
   - Changes made

2. Record any technical decisions with:
   - Clear rationale
   - Considered alternatives
   - Impact assessment

3. Update progress tracking:
   - Mark completed items
   - Add new tasks identified
   - Note any blockers found

Key Guidelines:
- NEVER proceed without checking memory bank context
- ALWAYS maintain consistent project state
- Record ALL significant technical decisions
- Track progress in real-time
- Keep context updated with EVERY change

Prompting technique: Mandatory pre-task read checklist + mandatory post-task write protocol. Rule-based imperative ("NEVER/ALWAYS") enforced entirely via prompt instruction, not code.

MCP Tool Usage Examples (from README)

use_mcp_tool('memory-bank', 'record_decision', {
  projectPath: '/path/to/project',
  decision: {
    title: 'Authentication System',
    description: 'Implementing JWT-based authentication',
    rationale: 'Better scalability and stateless operation',
    alternatives: ['Session-based auth', 'OAuth-only'],
    status: 'accepted',
    impact: 'Affects all API endpoints and user flows'
  }
});

Prompting technique: Structured JSON schema enforces decision capture with required fields (rationale, alternatives, status) — the schema acts as a cognitive checklist.

09

Uniqueness

cline-mcp-memory-bank — Uniqueness

Differs From Seeds

Closest to ccmemory (seed) in purpose — both provide persistent cross-session memory for an AI coding agent. The delta is substantial: ccmemory uses Neo4j graph + vector search + automatic lifecycle hooks; cline-mcp-memory-bank uses four flat Markdown files + manual MCP tool calls. ccmemory organizes memory into typed nodes (Decision, Correction, FailedApproach, etc.) with typed edges (SUPERSEDES, CONFLICTS_WITH); cline-mcp-memory-bank uses four fixed categories (projectContext, activeContext, progress, decisions) with no relational structure. ccmemory works only with Claude Code; cline-mcp-memory-bank works only with Cline. It is also similar to claude-conductor (seed) in its "markdown scaffold" archetype but adds MCP tooling on top.

Positioning

The simplest possible MCP-based memory system for Cline. No infrastructure dependencies (no Docker, no database, no API keys). Suitable for developers who want session continuity without operational complexity.

Observable Failure Modes

  1. No automatic capture: Developers must remember to call tools or instruct Cline to do so; sessions can end without any memory update.
  2. Unbounded growth: No pruning or summarization; files grow indefinitely, eventually becoming too large to be useful context.
  3. No search: With large memory banks, the agent must read all four files even if only one is relevant, wasting context budget.
  4. No conflict resolution: Contradictions between entries are not detected; stale decisions remain unless manually curated.
  5. Cline-only: No portability to other AI tools that could also use MCP.
04

Workflow

cline-mcp-memory-bank — Workflow

Phases

Phase Action Artifact
Setup Run initialize_memory_bank tool memory-bank/ directory with 4 Markdown files
Session Start Ask Cline "follow your custom instructions" or Cline reads memory-bank/ Loaded context from 4 files
Active Work Cline or user calls update_context as work proceeds Updated activeContext.md
Decision Made User/Cline calls record_decision Appended entry in decisionLog.md
Progress Update User/Cline calls track_progress Updated progress.md
Session End Manual — no auto-close hook Manually updated files

Approval Gates

None. No required checkpoints or human approvals defined by the framework. All tool calls are explicitly initiated.

System Prompt Template (from README — verbatim excerpt)

NEVER proceed without checking memory bank context
ALWAYS maintain consistent project state
Record ALL significant technical decisions
Track progress in real-time
Keep context updated with EVERY change

Spec Format

None. The memory files are free-form Markdown with suggested structure.

Key Limitation

All updates are pull-based (user or Cline must explicitly call the tools). Unlike hook-based systems, nothing captures context automatically when conversations end.

06

Memory Context

cline-mcp-memory-bank — Memory & Context

Memory Type

file-based — Four Markdown files in memory-bank/ at project root.

Persistence Scope

project — Memory lives in the project directory. Not global across projects.

State Files

File Content
memory-bank/projectContext.md Project overview, version, tech stack, dependencies, architecture, workflow
memory-bank/activeContext.md Current session date/mode, active tasks, open questions, recent updates
memory-bank/progress.md Current phase, milestones, completed/in-progress/upcoming tasks, blockers
memory-bank/decisionLog.md Chronological decision log with rationale, alternatives, status, impact

Search Mechanism

none — No search capability. Context is read by loading all four files at session start. With Cline, the agent reads the MCP resources via URI (memory://project/context, etc.).

Context Compaction Handling

no — No explicit compaction strategy. Files grow unbounded; no summarization, archiving, or pruning mechanism.

Cross-Session Handoffs

yes — This is the explicit purpose. The four files persist between sessions. Handoff depends entirely on the user/agent reading them at the start of each new session (no automatic injection).

Comparison to ccmemory (seed)

ccmemory uses Neo4j + vector indexes with automatic lifecycle hooks (SessionStart injects context automatically). cline-mcp-memory-bank is the minimal alternative: flat Markdown, no database, no hooks, all manual. The MCP layer only reads/writes files — it does not analyze or reason about content.

07

Orchestration

cline-mcp-memory-bank — Orchestration

Multi-Agent

No. Single-agent design. No spawning, delegation, or coordination primitives.

Orchestration Pattern

none — No orchestration. Sequential, single-turn tool calls initiated by the user or Cline.

Isolation Mechanism

none — No isolation. Operates in-place on the project directory.

Multi-Model

No. No model routing. Works with whatever model Cline uses.

Execution Mode

interactive-loop — Cline is interactive; the MCP tools are called on demand within Cline's conversation loop.

Crash Recovery

No explicit mechanism. Files are plain Markdown, so they survive process crashes by default.

Context Compaction

No strategy defined. If context gets large, no automatic pruning occurs.

08

Ui Cli Surface

cline-mcp-memory-bank — UI & CLI Surface

Dedicated CLI Binary

No standalone binary. The server is invoked as node build/index.js. The initialize_memory_bank . call functions as a one-time setup command.

Local Web Dashboard

None.

IDE Integration

Cline VSCode Extension exclusively. Configuration is in Cline's MCP settings JSON at a platform-specific path.

Observability

None. No logs, audit trail, or metrics. Markdown files are the only output.

Installation UX

Multi-step: clone repo, install deps, build, manually edit MCP settings file. The README provides a recommended automated alternative using the initialize_memory_bank CLI call.

Related frameworks

same archetype · same primary tool · same memory type

MemPalace ★ 53k
A10 Memory engine

Verbatim local-first AI memory with 96.6% R@5 retrieval on LongMemEval using zero API calls — structured into a palace hierarchy…

Beads (Yegge) ★ 24k
A10 Memory engine

Dolt-powered distributed graph issue tracker where AI agents track tasks with hierarchical IDs and dependency edges, claim work…

deepagents (LangChain) ★ 23k
A10 Memory engine

Opinionated Python agent harness on top of LangGraph with sub-agents, filesystem, memory, and context compaction bundled in

agentmemory ★ 18k
A10 Memory engine

Persistent, searchable memory for AI coding agents that captures every tool interaction, compresses it via LLM, and injects…

Open Multi-Agent ★ 6.3k
A10 Memory engine

Give a natural-language goal to a coordinator agent and get a dynamically decomposed, parallelized task DAG executed by…

Basic Memory ★ 3.1k
A10 Memory engine

Gives AI agents a persistent, human-readable knowledge graph of project decisions, observations, and relations stored as plain…