Marrow
Marrow is a persistent workspace MCP server for AI coding agents — it manages a project's task backlog, versioned Markdown artifacts, session/role context, semantic code search, and build manifests.
Task backlog: add, search (semantic + filters), inspect, update, and complete tasks, with automatic dependency unblocking when tasks close.
Artifacts: batch read/write Markdown files (full, paged, section, line-range, patch, replace/append/delete section), list, move, delete to recycle bin, and full-text search them.
Semantic artifact search: meaning-based search over artifact chunks, optionally scoped to directories.
Version control for docs: list backup snapshots of any artifact and restore a previous version.
Code intelligence (needs a worker): semantic search over indexed code skeletons, token-efficient file outlines, live line-range source reading, and a directory map of indexed files.
Session continuity: read session state plus role-specific guidelines and ADRs, or fetch a role's full context bundle for mid-session role switches.
Project management: list projects and create new ones from the built-in template.
Builds: run YAML build manifests that assemble context payloads, with runtime template variables.
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 |
| 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). |
| 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. |
| Shared data contract ( |
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 | |
Try it without installing anything | |
Develop or hack on Marrow itself |
Option A — Docker (recommended)
You need: Docker with Docker Compose.
How Docker storage works here:
docker-compose.ymluses named volumes —marrow-data(mounted at/datain the server;TASKS_DIR=/data, so your projects live at/data/projects/<name>inside the volume) andmarrow-projects— the source code volume (mounted read-only at/projectsin 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.ymlWindows PowerShell alternative (plain curl -O behaves differently there):
Invoke-WebRequest -OutFile docker-compose.yml https://raw.githubusercontent.com/desikai-lab/Marrow/main/docker-compose.ymlOr 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/src3. Start it
docker compose upMarrow 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 psmarrow-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-serverWhy 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.
Install Marrow from the marketplace and set
SECRET_TOKENin the environment settings.In the Glama inspector, call
init_projectonce to create your first project:
{ "tool": "init_project", "arguments": { "project": "default" } }Connect your agent and call
get_session_contextto 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 runningmarrow_workerwith 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 Marrow2. 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.pyThe server listens on http://localhost:8000/mcp by default.
3. Create a project
marrow-admin project-init --project MyProjectThis 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/code5. 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:
Verify the connection. Ask the agent to call
get_session_contextfor your project (for exampleMyProject). It returns the current phase, guidelines and next step.Fill in
spec.md. This is the project specification every future session reads first. Keep your stack and architectural rules there.Add work to the backlog. Ask the agent to create tasks with
add_tasks, then find them later withsearch_tasks.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.Hand off. At the end of a session the agent saves state to
session.md. The next agent, on any model, starts fromget_session_context.
MCP tool reference
All tools work with any MCP-compatible client.
Tool | Description |
| Add tasks to the project backlog |
| Semantic search over tasks |
| Full details of a task by ID |
| Update task fields (status, priority, …) |
| Close tasks and automatically unblock dependents |
Tool | Description |
| Read one or more Markdown artifacts |
| Create or update artifacts (patch, replace, append) |
| List files in artifact storage |
| Move or rename an artifact |
| Safely delete an artifact |
| Search across all artifacts |
| Semantic search over artifact chunks, optionally scoped to directories |
| Table of contents of a Markdown file |
| Version history of an artifact |
| Restore a previous version |
Tool | Description |
| Semantic search over indexed code |
| Token-efficient structural outline of a file |
| Read an exact line range from the live repository |
| Directory tree of all indexed files |
Tool | Description |
| List all available projects |
| Create a project from the built-in template (ideal for Glama or any deployment without a shell) |
| Read session state and return guidelines for the active agent role. Call this first in every session. |
| 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 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=onblends 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 OtherAppIn 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 |
REST returns 401 Unauthorized | Wrong/missing project key, key sent in query string (header only), unknown project in path, or you used |
Code tools ( | Check that |
Semantic code search returns nothing on a new project | The initial scan may still be running. Start the worker once with |
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_HEREGenerate 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_TOKENdoes 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-contextSuccess: {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: 1Workspace 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 blueprintsDocumentation
Doc | Covers |
All environment variables and CLI arguments for server, worker and docker-compose | |
| |
Build manifest YAML format and the |
Contributing
See CONTRIBUTING.md for development setup, coding standards and the pull request process.
License
MIT. See LICENSE.
Available Tools
19 toolsadd_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
semantic_searchA
[ARTIFACT TOOLS] Semantic search over artifact chunks, optionally scoped to one or more directories; returns each hit's location plus file content. Read-only.
Parameters: project : project name. query : natural-language search text. limit : max hits. With scopes, applies to the combined OR result, not per scope. scopes : project-relative directory paths, max 20, OR semantics. Omit (or None/[]) for unscoped -- unchanged from before this param existed. Directories only; a file path simply matches nothing.
Returns: on a normal or unscoped call, a list of hits (path, section,
start_line, end_line, distance, content, warning -- as before). If
scopes matched zero chunks, returns a single object instead of a list:
{"message": str} explaining why -- check for a "message" key, not list
length, to tell the two shapes apart.
Raises: 404 unknown project. Validation error for a bad scope (absolute,
'..', outside project root) or >20 scopes -- names the scope, never a
host path. Per-hit read failures set warning (partial success), not an exception.
Do NOT use to read a known file -- call read_project_artifacts instead. Do NOT pass a file path as a scope -- scopes are directories.
Inputs: query (required), project (required), limit, scopes.
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
Scored across 19 tools
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.
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.
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.
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
Related MCP Connectors
Team memory for AI coding agents and code reviews, reviewed by humans and served over MCP.
Persistent engineering memory designed to follow developers across coding agents.
Persistent memory, knowledge graph, task management and more for AI agents via MCP.
shared AI-context layer for teams — persistent memory your agents search and update over MCP
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables 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.4MIT
- AlicenseAqualityDmaintenanceMCP server that provides a shared semantic memory layer for AI coding agents, enabling teams to store, search, and sync context, decisions, and knowledge across projects with project-based isolation and multi-backend support.141MIT
- AlicenseNot gradedqualityBmaintenanceEnables 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
- AlicenseNot gradedqualityBmaintenanceEnables 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