Skip to main content
Glama

Marrow MCP server

Marrow

Give your AI coding agents memory that survives between sessions.

Marrow is an MCP server that fixes agent amnesia. It gives any MCP-compatible agent (Claude, Cursor, custom agents) a persistent workspace with:

  • Session state: pick up exactly where the last session stopped

  • Task backlog: with semantic search and automatic dependency unblocking

  • Versioned documents: history and rollback for specs, plans and decisions

  • Semantic code search: find code by meaning, not just by filename

Jump to: Quickstart · Your first session · Tool reference · Troubleshooting · REST API · Docs

Why Marrow?

AI coding agents are stateless. Every new session starts cold: no memory of what was decided, what was built, or where things stand.

Without Marrow

With Marrow

Agent forgets context between sessions

Session state is persisted and recoverable

Agent searches code by filename

Agent searches code by semantic meaning

Notes and plans live in chat history

Versioned artifact storage with history and rollback

Tasks tracked in external tools

Native task backlog with semantic search

Build context assembled by hand

Declarative build manifests assemble it automatically

Typical use: multi-agent handoff. Use a strong model for architecture and let it save its decisions into Marrow. Then start a cheaper or local model to write the tests. The second agent calls get_session_context and is immediately aligned.

Related MCP server: SyncContext

How it works

 Your source code ──► marrow_worker ──────────► marrow_server ◄──── Your AI agent
 (watched live)       parses files into          stores tasks, docs   (via MCP over
                      skeletons + embeddings     and the code index   HTTP)

Component

What it does

marrow_server

The main service. Exposes the MCP tools and a REST API for the worker. Stores data in LanceDB (vectors and metadata) plus Markdown blobs (tasks and artifacts).

marrow_worker

Background daemon. Watches your source files, extracts classes, methods and namespaces with tree-sitter, embeds them, and sends them to the server in resilient batches.

marrow_common

Shared data contract (SkeletonChunk, SCHEMA_VERSION) between worker and server.

marrow_server is a FastAPI + FastMCP app (Streamable HTTP MCP, protocol 2025-03-26). Storage is LanceDB for embeddings/metadata plus Markdown blobs for task and artifact content. The REST API is a sibling ASGI app behind a PrefixDispatcher, sharing the operations/ layer with MCP (see ADR-0053, ADR-0054).

Full service architecture, layer map (transport / services / storage / tools), and worker pipeline → marrow_server/README.md.

Quickstart (5 minutes)

Pick one path:

I want to…

Use

Run it locally with everything included

Option A: Docker

Try it without installing anything

Option B: Glama

Develop or hack on Marrow itself

Option C: Manual

You need: Docker with Docker Compose.

How Docker storage works here: docker-compose.yml uses named volumes — marrow-data (mounted at /data in the server; TASKS_DIR=/data, so your projects live at /data/projects/<name> inside the volume) and marrow-projects — the source code volume (mounted read-only at /projects in both server and worker; the worker indexes whatever is visible there). This compose file defines no host mount, so until your repositories are present in the volume, the code intelligence tools stay empty. A host mount for this volume is planned as a follow-up.

1. Get the compose file

curl -O https://raw.githubusercontent.com/desikai-lab/Marrow/main/docker-compose.yml

Windows PowerShell alternative (plain curl -O behaves differently there):

Invoke-WebRequest -OutFile docker-compose.yml https://raw.githubusercontent.com/desikai-lab/Marrow/main/docker-compose.yml

Or git clone https://github.com/desikai-lab/Marrow.git && cd Marrow.

2. Create a .env file next to docker-compose.yml:

# Required: the token your agent must send as a Bearer token (use at least 16 characters)
SECRET_TOKEN=your-strong-random-secret

# Name of the first project, auto-created on first run
DEFAULT_PROJECT=MyProject

# Worker for the first project.
# PROJECT_1_PATH becomes /projects/<PROJECT_1_PATH> inside the containers.
PROJECT_1_NAME=MyProject
PROJECT_1_PATH=MyApp/src

3. Start it

docker compose up

Marrow pulls the pre-built images, creates your first project, then starts the server and worker. The first run takes about 20 seconds while the embedding model downloads.

Check that it worked:

docker compose ps

marrow-server should show healthy (the compose healthcheck calls GET /health).

4. Point the project at your code

TASKS_DIR is /data in Docker (the marrow-data volume), so the project's .settings file lives at /data/projects/MyProject/.settings as seen by the server. Create it with:

docker compose exec marrow-server sh -c "cat > /data/projects/MyProject/.settings <<'EOF'
SOURCE_ROOT=/projects/MyApp/src
EOF"

Restart the server afterwards so it picks up the new file (project settings are cached on first read):

docker compose restart marrow-server

Why this matters is explained in Project settings.

5. Connect your agent

Add Marrow to your MCP client config (for Cursor, ~/.cursor/mcp.json):

{
  "mcpServers": {
    "marrow": {
      "url": "http://localhost:8000/mcp",
      "headers": {
        "Authorization": "Bearer your-strong-random-secret"
      }
    }
  }
}

MCP endpoint: http://localhost:8000/mcp. Next: Your first session.

Option B — Glama (hosted, no shell access)

Marrow runs as a hosted MCP server on the Glama marketplace. Glama manages the container, so you need no Docker or shell.

  1. Install Marrow from the marketplace and set SECRET_TOKEN in the environment settings.

  2. In the Glama inspector, call init_project once to create your first project:

{ "tool": "init_project", "arguments": { "project": "default" } }
  1. Connect your agent and call get_session_context to verify the workspace is ready.

Call init_project again with a new name for each additional project.

Limitation: code intelligence tools (search_code_skeletons, view_file_source, …) need a running marrow_worker with access to your source code. On Glama they are unavailable unless you run a worker yourself and point it at the Glama server URL.

Option C — Manual / development setup

You need: Python 3.12+. Dependencies (LanceDB, tree-sitter grammars, a sentence-transformer embedding model) are installed by pip install -e .. See ADR-0022 for grammar details.

1. Clone

git clone https://github.com/desikai-lab/Marrow.git
cd Marrow

2. Start the server

cd marrow_server
python -m venv .venv
source .venv/bin/activate      # Windows: .venv\Scripts\activate
pip install -e .
cp .env.example .env           # set SECRET_TOKEN and TASKS_DIR (both required)
python src/marrow_server.py

The server listens on http://localhost:8000/mcp by default.

3. Create a project

marrow-admin project-init --project MyProject

This copies the built-in template into TASKS_DIR/projects/MyProject/. Open its spec.md and fill in your tech stack before the first agent session. All admin commands are in docs/ADMIN_CLI.md.

4. Point the project at your code

# TASKS_DIR/projects/MyProject/.settings
SOURCE_ROOT=/absolute/path/to/your/source/code

5. Start the worker (separate terminal)

cd marrow_worker
pip install -e .
python main.py \
  --repo-dir /absolute/path/to/your/source/code \
  --project-name MyProject \
  --target-url http://localhost:8000 \
  --secret-token your-strong-random-secret \
  --init

--init runs a full initial scan. Omit it on later runs.

6. Connect your agent with the same JSON config shown in Option A, step 5.

Your first session

Once your agent is connected:

  1. Verify the connection. Ask the agent to call get_session_context for your project (for example MyProject). It returns the current phase, guidelines and next step.

  2. Fill in spec.md. This is the project specification every future session reads first. Keep your stack and architectural rules there.

  3. Add work to the backlog. Ask the agent to create tasks with add_tasks, then find them later with search_tasks.

  4. Try semantic code search. Once the worker has finished its initial scan, ask something like “find where we validate user input”. The agent will use search_code_skeletons.

  5. Hand off. At the end of a session the agent saves state to session.md. The next agent, on any model, starts from get_session_context.

MCP tool reference

All tools work with any MCP-compatible client.

Tool

Description

add_tasks

Add tasks to the project backlog

search_tasks

Semantic search over tasks

get_task_details

Full details of a task by ID

update_task

Update task fields (status, priority, …)

complete_tasks

Close tasks and automatically unblock dependents

Tool

Description

read_project_artifacts

Read one or more Markdown artifacts

save_project_artifacts

Create or update artifacts (patch, replace, append)

list_project_artifacts

List files in artifact storage

move_project_artifact

Move or rename an artifact

delete_project_artifact

Safely delete an artifact

search_project_artifacts

Search across all artifacts

semantic_search

Semantic search over artifact chunks, optionally scoped to directories

get_project_artifact_outline

Table of contents of a Markdown file

list_artifact_history

Version history of an artifact

restore_project_artifact

Restore a previous version

Tool

Description

search_code_skeletons

Semantic search over indexed code

get_file_skeleton

Token-efficient structural outline of a file

view_file_source

Read an exact line range from the live repository

get_project_map

Directory tree of all indexed files

Tool

Description

list_projects

List all available projects

init_project

Create a project from the built-in template (ideal for Glama or any deployment without a shell)

get_session_context

Read session state and return guidelines for the active agent role. Call this first in every session.

get_guideline

Return the full context bundle (guidelines and ADRs) for a named role, for mid-session role switches that leave pipeline state untouched

Tool

Description

run_project_build

Run a YAML build manifest to assemble context payloads (see docs/BUILD_ENGINE.md)

Project settings (.settings)

Each project workspace has a .settings file that tells the server where your source code lives. Without it, code intelligence tools are disabled for that project.

Location: TASKS_DIR/projects/{project_name}/.settings

# Absolute path to the source root, as seen from inside the server container
SOURCE_ROOT=/projects/MyApp/src

# Optional. Experimental keyword blending for artifact search. Default: off
LITERAL_EXTRACTION=off

# Optional. REST API keys for third-party access (see [REST API](#rest-api-for-third-parties)).
# API_KEYS=label:key,label:key

LITERAL_EXTRACTION=on blends keyword signals (BM25 + RRF) into natural-language artifact search. It is experimental and tuned for English text — non-English artifacts may produce low-quality keyword tokens or fallback stubs.

The one rule: three paths must agree. SOURCE_ROOT in .settings, the server's mount, and the worker's --repo-dir must all be the same path. Both containers mount the same volume at /projects, so a project's path is identical everywhere:

Inside server AND worker containers
/projects/                      (marrow-projects named volume in Docker)
  ├── MyApp/src/
  └── OtherApp/src/

TASKS_DIR/projects/
  ├── MyApp/.settings        →  SOURCE_ROOT=/projects/MyApp/src
  └── OtherApp/.settings     →  SOURCE_ROOT=/projects/OtherApp/src

Worker for MyApp:    --repo-dir /projects/MyApp/src    --project-name MyApp
Worker for OtherApp: --repo-dir /projects/OtherApp/src --project-name OtherApp

In Docker, /projects is the marrow-projects source code volume shared by server and worker (see Option A); for a manual setup it is any local path both processes can see, e.g. SOURCE_ROOT=/absolute/path/to/your/source/code with the same value passed as the worker's --repo-dir.

Give each project its own .settings and its own worker service in docker-compose.yml (a commented template block is included).

Troubleshooting

Symptom

Likely cause and fix

Agent gets 401 / unauthorized (MCP)

The Authorization: Bearer … value in the client config differs from SECRET_TOKEN on the server.

REST returns 401 Unauthorized

Wrong/missing project key, key sent in query string (header only), unknown project in path, or you used SECRET_TOKEN on REST / project key on MCP — they are not interchangeable. Check API_KEYS in .settings.

Code tools (search_code_skeletons, view_file_source, …) are disabled or empty

Check that .settings exists with SOURCE_ROOT, that it matches the worker's --repo-dir, and that the worker is running.

Semantic code search returns nothing on a new project

The initial scan may still be running. Start the worker once with --init.

First start is slow

The embedding model is downloading (about 20 seconds). Wait for it to finish.

Code tools do not work on Glama

Expected. Run your own worker against the Glama server URL (see Option B).

Still stuck? Open an issue.

REST API for third parties

21 of Marrow's 24 MCP operations are also available over authenticated REST for non-MCP clients (scripts, CI, third-party services). Same operations/ layer as MCP — field names equal MCP tool parameter names (bound by CI parity test).

Base URL: /api/v1/projects/{project} — project always comes from the path. Not exposed: list_projects, init_project, run_project_build.

1. Enable it (default is on)

# .env — server side
REST_API_ENABLED=true   # set to false to disable /api/v1 (requests fall through to MCP app)

2. Create a project key

Keys live in the project workspace .settings file (outside artifacts/), NOT in .env:

# TASKS_DIR/projects/MyProject/.settings
SOURCE_ROOT=/projects/MyApp/src
API_KEYS=ci:mk_YOUR_GENERATED_KEY_HERE

Generate a key (shape: mk_ + 32–128 url-safe chars):

python -c 'import secrets; print("mk_" + secrets.token_urlsafe(32))'

Rules:

  • Label shape: [A-Za-z0-9][A-Za-z0-9_-]{0,31}. Multiple keys per project: API_KEYS=label1:key1,label2:key2.

  • Duplicate labels or duplicate key values are dropped with a warning.

  • Rotate without restart: append new entry → move consumer → remove old entry. Takes effect on next request (60 s cache backstop).

  • chmod 600 .settings — it now holds credentials.

  • Every key has full access to its project (artifact writes included).

  • SECRET_TOKEN does NOT work on REST; project keys do NOT work on MCP (/mcp) or /api/vectorize. Tokens in query string are ignored (401).

3. Call it

Header only — Authorization: Bearer mk_…:

curl -H 'Authorization: Bearer mk_...' http://localhost:8000/api/v1/projects/MyProject/session-context

Success: {result, request_id}. Error: {error: {type, message}, request_id} + X-Request-Id header. Machine-readable contract (key required): GET /api/v1/projects/{project}/openapi.json — no interactive docs UI.

REST_CORS_ORIGINS=              # comma-separated origins; empty (default) = no CORS headers
REST_KEY_CACHE_MAX_AGE_S=60     # key cache TTL, clamped 1..300
REST_MAX_BODY_BYTES=5242880     # 5 MiB; over cap = 413
REST_MAX_CONCURRENCY=16         # saturated = 503 + Retry-After: 1

Workspace layout

Each project lives in TASKS_DIR/projects/{project_name}/:

{project_name}/
├── .db               # Vector database and task blobs
├── .history          # File version history
├── .recycle_bin      # Deleted artifacts
├── .settings         # Per-project config, e.g. SOURCE_ROOT
└── artifacts/        # Root folder the agent can read and write
    ├── session.md    # Session state: current focus, pipeline phase
    ├── spec.md       # Project spec and architectural constants
    ├── builds/       # YAML build manifests
    └── docs/
        ├── decisions/adr/   # Architectural Decision Records
        ├── features/
        │   ├── active/      # Features in development
        │   └── archive/     # Completed work
        ├── manuals/         # Guidelines and operational docs
        └── templates/       # Standardization blueprints

Documentation

Doc

Covers

docs/CONFIGURATION.md

All environment variables and CLI arguments for server, worker and docker-compose

docs/ADMIN_CLI.md

marrow-admin and marrow-skills commands, and repair_blobs.py

docs/BUILD_ENGINE.md

Build manifest YAML format and the build admin command

Contributing

See CONTRIBUTING.md for development setup, coding standards and the pull request process.

License

MIT. See LICENSE.

Available Tools

19 tools
add_tasksA

[TASK TOOLS] Adds a list of tasks to the project backlog.

Inputs: tasks (required), project (required). Returns: result

complete_tasksA

[TASK TOOLS] Atomically closes one or more tasks and auto-unblocks dependents.

Inputs: project (required), task_ids (required). Returns: result

delete_project_artifactA

[ARTIFACT TOOLS] Deletes a single artifact file by moving it to the recycle bin. The file is preserved in the recycle bin and can be restored using restore_project_artifact if needed.

Do NOT use to move or rename a file — call move_project_artifact instead.

Returns: confirmation string with the deleted file path. Raises: 404 error if the path does not exist in artifact storage.

Inputs: path (required), project (required). Returns: result

get_guidelineA

[SESSION TOOLS] Assembles and returns the full context bundle (core guidelines + role-specific phase guidelines + filtered foundational ADRs) for a named agent role, without reading or modifying session.md.

Use this for deliberate mid-session role switches when you already know the target role and do not want to disturb pipeline state. Do NOT use at session start — call get_session_context instead, which also injects the SESSION STATE block and the correct NEXT STEP directive.

Allowed role values: any role registered in the project's role_profiles.yaml (e.g. 'discovery', 'architecture', 'planning', 'execution'). Returns an error string listing valid roles if the value is unrecognised.

Returns: assembled markdown string (core guidelines + role guidelines + ADRs). Raises: error string if role is not registered in role_profiles.yaml.

Inputs: role (required), project (required). Returns: result

get_project_artifact_outlineB

[ARTIFACT TOOLS] Extracts table of contents.

Inputs: path (required), project (required). Returns: result

get_session_contextA

[SESSION TOOLS] Reads session.md, detects the active pipeline phase, and returns core guidelines + phase-appropriate role guidelines + filtered foundational ADRs

  • role-linked skill stubs (=== PLAYBOOKS === section, when the role has skills registered) as a single assembled string.

If start_role is provided, session.md is bypassed entirely: the named role is resolved directly and SESSION STATE is omitted from the response.

Inputs: project (required), start_role. Returns: result

get_task_detailsB

[TASK TOOLS] Returns full task details.

Inputs: project (required), task_id (required).

init_projectA

[PROJECT TOOLS] Creates a new Marrow project workspace by copying the built-in default template into TASKS_DIR/projects/{project}. Produces a ready-to-use artifact tree (session.md, spec.md, guidelines, role_profiles.yaml).

Primary use case: first-run initialization on Glama or any single-container deployment where shell access is unavailable. For docker-compose deployments, use the marrow-init service instead.

Do NOT use to list existing projects — call list_projects instead. Do NOT use to read session state — call get_session_context(project) after init.

Parameters: project : str — unique project name (must not already exist) template : str — scaffold template; only "default" is supported in this release

Returns: { project, files_created, starting_role } where files_created lists every file path copied into the new workspace (relative to workspace root) and starting_role is Discovery Agent or Init Agent.

Raises: ValidationError if project already exists or template is unsupported.

Inputs: project (required), template. Returns: object

list_artifact_historyA

[HISTORY TOOLS] Returns the version history for a single artifact file — a list of backup snapshots automatically created by save_project_artifacts on each write. Each entry represents a point-in-time copy that can be restored.

Use this to inspect available versions before calling restore_project_artifact. The most recent backup is listed first. Do NOT use this to read current file content — call read_project_artifacts instead.

Returns: list of version objects — each with backup_name, created_at timestamp, and size in bytes. Empty list if no history exists for the path. Raises: 404 if the artifact path does not exist in the project.

Inputs: path (required), project (required). Returns: result

list_project_artifactsA

[ARTIFACT TOOLS] Lists artifact files in a project's artifact storage, optionally scoped to a subfolder and optionally traversing subdirectories.

path narrows the listing to a specific folder (e.g. 'docs/features/active'); omit or pass '' to list from the project root. recursive=True traverses all subdirectories; default is False (top-level only).

Do NOT use to read file content — call read_project_artifacts instead. Do NOT use to browse source code — call get_project_map for the src/ tree.

Returns: list of objects — each with path (relative to project root) and size in bytes. Raises: 404 if the project or path does not exist.

Inputs: project (required), path, recursive. Returns: result

list_projectsB

[PROJECT TOOLS] Returns a list of all available projects.

Inputs: no named parameters. Returns: result

move_project_artifactB

[ARTIFACT TOOLS] Moves or renames an artifact.

Inputs: project (required), src_path (required), dest_path (required). Returns: result

read_project_artifactsA

[ARTIFACT TOOLS] Reads one or more artifact files in a single batch call. Each item in reads targets one file and specifies an independent read mode.

Read modes per item: full — returns the entire file content. paged — windowed read of the entire file. max_chars (default 10000), skip_chars, and direction (default). section — returns only the content under a named ## header (requires section_name). lines — returns a specific line range (requires start_line and end_line).

Optional per-item fields: max_chars : int — truncate response at N characters (default 10000). skip_chars : int — skip N characters from the start of the selection. direction : 'begin' | 'end' — read from start or end of file (default 'begin'). line_numbers : bool — prefix each line with its 1-based line number.

Do NOT loop this tool per file — batch all reads into a single call to minimise round-trips. For source code files in src/, use view_file_source instead.

Returns: list of result objects — each with path and content (or error if not found). Raises: per-item error entry if a path does not exist; does not abort the batch.

Inputs: reads (required), project (required). Returns: result

restore_project_artifactA

[HISTORY TOOLS] Restores a named backup snapshot of an artifact, replacing the current live file with the backup content. The current live version is NOT automatically backed up before the restore — it will be overwritten.

Use list_artifact_history first to retrieve valid backup_name values for the target path. The backup_name is the exact string returned in the history list. Do NOT guess or construct backup names — always read them from list_artifact_history.

Returns: confirmation string with the restored path and backup_name applied. Raises: 404 if the path or backup_name does not exist.

Inputs: path (required), project (required), backup_name (required). Returns: result

save_project_artifactsA

[ARTIFACT TOOLS] Creates or updates one or more artifact files in a single atomic batch. Each item in updates targets one file and specifies an independent write mode — modes in the same batch do not interact.

Write modes per update item: replace_file — overwrites the entire file (creates it if absent). replace_section — replaces the content under a named ## header; raises if the header appears more than once (ADR-0011). append_section — appends a new ## section at the end of the file. replace_chunk — replaces lines start_line..end_line with new content. patch — finds old_str (must be unique in the file) and replaces it with new content. Preferred for surgical single-line edits. delete_section — removes a named ## section and its content.

Do NOT use replace_file when only a section needs updating — use patch or replace_section to avoid clobbering concurrent edits. Do NOT use this tool for source code in src/ — the source directory is read-only from the agent's perspective.

Returns: list of result objects, one per update — each with path and status. Raises: duplicate-header error (with line numbers) if replace_section finds multiple matching headers in the same file.

Inputs: project (required), updates (required). Returns: result

search_project_artifactsA

[ARTIFACT TOOLS] Full-text search across all artifact files in a project, matching against file content and returning files and sections that contain the query string.

Query is plain text — no special syntax required. Case-insensitive. For semantic / meaning-based search, use semantic_search instead. Do NOT use this to list files — call list_project_artifacts instead. Do NOT use this for source code — call search_code_skeletons instead.

Returns: list of match objects — each with path, matched section name, and a short excerpt of the matched content with surrounding context. Raises: 404 if the project does not exist.

Inputs: query (required), project (required). Returns: result

search_tasksA

[TASK TOOLS] Queries the task backlog in LanceDB with optional filters and returns matching task summaries ranked by creation order.

All parameters are optional filters — omit to retrieve all tasks with default status. Default status filter is 'open'; pass status=None to retrieve tasks of all statuses. Do NOT call get_task_details on every result — use this tool for status checks and task selection, then call get_task_details on the single selected task for full content.

Allowed status values: open | in_progress | blocked | done | None (no filter) Allowed priority values: low | medium | high | critical | None (no filter) Allowed type values: feature | bug | task | td | None (no filter)

Returns: list of task summary objects — each with task_id, title, status, priority, type, and blocked_by. Full problem/solution content is excluded; call get_task_details for that. Raises: 404 if project is not found.

Inputs: project (required), type, status, priority. Returns: result

update_taskA

[TASK TOOLS] Partially updates mutable fields on an existing task (status, priority, title, solution, etc.) using a merge strategy — only keys present in updates are changed; all other fields remain intact. Use this for in-progress changes (e.g. updating priority or editing the solution).

Do NOT use to close a task — call complete_tasks instead, which atomically closes and auto-unblocks dependents. Do NOT use to create tasks — call add_tasks instead.

Allowed updates keys: status : open | in_progress | blocked | done priority : low | medium | high | critical title : str problem : str solution : str blocked_by : list[task_id]

Returns: updated task object with all current field values. Raises: 404 if task_id not found in project.

Inputs: project (required), task_id (required), updates (required).

Tool Schema Changelog

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

Loading tool schema changelog…

    TDQS

    A3.9/5.0

    Scored across 19 tools

    Disambiguation5/5

    Each tool targets a distinct resource/action, and descriptions explicitly delimit overlapping cases such as full-text search vs. semantic search and update_task vs. complete_tasks. The role/session tools are also clearly differentiated between session start and mid-session role switching.

    Naming Consistency4/5

    Almost all tools use consistent snake_case verb_noun naming, such as list_project_artifacts, save_project_artifacts, and complete_tasks. Minor deviations exist with semantic_search and singular/plural variation between update_task and add_tasks/search_tasks, but the pattern remains highly readable.

    Tool Count4/5

    Nineteen tools is slightly heavy for the typical 3–15 range, but the server spans artifacts, tasks, projects, and sessions, so each tool has a plausible role. The count is reasonable overall, though the surface is broader than a tightly scoped server.

    Completeness3/5

    Artifact lifecycle coverage is strong, including read, save, list, search, move, delete, history, and restore, but the task and project surfaces lack deletion/get-details operations. More importantly, descriptions reference source-browsing tools such as view_file_source, get_project_map, and search_code_skeletons that are absent from the tool set, creating dead ends.

    Maintenance

    ActivityActive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      B
      maintenance
      Enables AI coding agents to maintain persistent, cross-session memory of codebase architecture, naming conventions, and decisions through MCP tools. Eliminates repetitive project re-explanation by automatically injecting stored context into every session with local-first SQLite storage and optional team sharing capabilities.
      4
      MIT
    • A
      license
      Not graded
      quality
      B
      maintenance
      Enables AI coding agents to share a persistent local-first memory hub, storing and recalling architectural decisions and context across different tools via MCP, so users can switch assistants without losing context.
      Apache 2.0
    • A
      license
      Not graded
      quality
      B
      maintenance
      Enables AI coding agents and assistants to share a local-first, token-efficient persistent memory layer across MCP-compatible runtimes, storing typed project facts, decisions, failures, and solutions with temporal validity. It supports offline use and Postgres-compatible storage, so agents can retrieve relevant context without re-embedding entire repositories.
      Apache 2.0