What can you do with this server?

The cc-mem-mcp server provides lossless, categorized long-term memory for Claude Code (and any MCP client), backed by Qdrant vector storage — preserving context across compaction generations that would otherwise lose details. * Initialize project memory (memory_init): Bootstrap memory for a repo by scanning it into categorized baselines (overview, stack, structure, commands, connections, git, docs), folding in existing compaction summaries, and optionally installing a managed block in CLAUDE.md with PostCompact/SessionStart hooks. * Ingest compaction summaries (memory_ingest): Automatically read Claude Code's JSONL transcripts, parse numbered sections into categorized chunks, and store them deduped across compaction generations — losslessly. * Semantic search (memory_find): Query stored memory using natural language, with optional filtering by category (e.g. code.connections, business.goal) and/or project slug, returning top matches with similarity scores. * Manually store a fact (memory_store): Write a single durable fact directly to memory with a category, project scope, tags, and source annotation. * Delete a fact (memory_delete): Remove a specific memory chunk by its ID. * Browse the category taxonomy (memory_categories): List all active category domains and sub-categories (e.g. code.rules, code.workflow, business.decision). * Inspect memory stats (memory_stats): View collection size, storage backend (embedded local or shared Qdrant server), and current embedding model configuration. Deployment & configuration: Supports local (embedded Qdrant) or shared Qdrant server, Docker or source installation, multiple embedding providers (local FastEmbed or OpenAI), multilingual models, and customizable category strictness via environment variables.

How do I use cc-mem-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cc-mem-mcp find memory about the deployment process" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

cc-mem-mcp

by NguyenSen

Overview Schema Related Servers Score Discussions

Python

Hybrid

cc-mem-mcp

Lossless, categorized long-term memory for Claude Code (and any MCP client), backed by Qdrant.

Compaction summaries grow without bound and lose a little more every time they're re-summarized — after enough rounds, facts will be dropped. But Claude Code already produces a categorized, updated state at each compaction (its numbered summary: Primary Request, Files and Code Sections, Errors and fixes, Pending Tasks, …). This server's job is not to invent its own taxonomy — it is to capture that summary the moment it's written and keep it losslessly across every compaction generation, so a detail dropped by compaction #7 is still retrievable from #2.

Claude Code writes ~/.claude/projects/<slug>/*.jsonl
        │  (each compaction appends an isCompactSummary line — already categorized)
        ▼
  cc-mem-ingest  ──►  parse numbered sections = categories
        │              split into chunks, content-hash dedup across generations
        ▼
  ┌──────────────────────── Qdrant ────────────────────────┐
  │  embedded local-file (default)  or  shared server (URL) │
  │  payload: category · project · generation · ts          │
  └──────────────────────────────────────────────────────────┘
        ▲
        │  memory_find(query, category?, project?)   ← retrieve on demand
   the agent reloads relevant state instead of trusting the lossy summary

The categories are whatever Claude Code produced — not an enum we impose. An optional built-in taxonomy (code.* / business.*) exists only as a suggestion for the manual memory_store path; set CC_MEM_STRICT_CATEGORIES=1 if you actually want it enforced.

Lifecycle: init → auto-update → query

memory_init  ──►  scan repo (project.* baseline)  +  fold in current session context
   (once)          + install a managed block in CLAUDE.md so the agent knows to query/update
      │
      ▼
auto-update  ──►  every compaction is captured by a PostCompact hook / watcher (cc-mem-ingest)
      │
      ▼
query        ──►  memory_find(query, category?, project?)   ← agent reloads state on demand

Init creates the first state and wires Claude Code up in one call:

cc-mem-init                       # scans cwd, ingests current context, writes CLAUDE.md block
cc-mem-init --install-hooks       # also add SessionStart + PostCompact hooks to settings.json

It scans the repo into project.overview / stack / structure / commands / connections / git / docs, derives the Claude Code transcript folder from the repo path to fold in the current session, and installs a managed ## Long-term Memory block in CLAUDE.md telling the agent to memory_find before re-deriving and to rely on automatic updates. Re-run anytime — it's idempotent.

Related MCP server: Mnemoverse Memory

Tools

Tool	Purpose
`memory_init(root?, project?, install_claude_md=true, install_hooks=false)`	Bootstrap. Scan repo → baseline, fold in current context, install CLAUDE.md guidance.
`memory_ingest(project?, session_path?)`	Auto-update. Capture Claude Code's compaction summaries from disk. Idempotent.
`memory_find(query, category?, project?, limit=5)`	Query. Semantic retrieval, filterable by category/project.
`memory_store(content, category, project?, tags?, source?)`	Optional manual write-through for a single fact.
`memory_categories()`	List the suggestion taxonomy.
`memory_delete(id)`	Remove a chunk by id.
`memory_stats()`	Collection size, backend, embedding config.

Capture: keeping compactions losslessly

Ingestion is idempotent (identical chunks re-map to the same id), so run it however you like:

# one-shot, current project
cc-mem-ingest --project <transcript-folder-slug>

# background watcher (polls every 30s)
cc-mem-ingest --watch --interval 30

# or wire it to Claude Code's PostCompact hook (fires right after each compaction)
#   settings.json:
#   { "hooks": { "PostCompact": [ { "matcher": "*", "hooks": [
#       { "type": "command", "command": "cc-mem-ingest --once" } ] } ] } }

Then, in-session, the agent calls memory_find (or memory_ingest on demand) to reload state after a compaction. See examples/CLAUDE.snippet.md.

Quick start (Docker)

Build:

docker build -t cc-mem-mcp .

Wire it into Claude Code — add to .mcp.json (project) or ~/.claude.json (global):

{
  "mcpServers": {
    "memory": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-v", "cc-mem-data:/data", "cc-mem-mcp"]
    }
  }
}

That's it — embedded Qdrant persists in the cc-mem-data volume, embeddings run locally via FastEmbed (no API key). See examples/ for shared-server and OpenAI variants.

Then paste examples/CLAUDE.snippet.md into your CLAUDE.md so the agent writes through and retrieves automatically.

Configuration

All via environment variables (see .env.example):

Var	Default	Meaning
`QDRANT_URL`	(unset)	Set to use a shared Qdrant server; unset = embedded local file.
`QDRANT_API_KEY`	(unset)	API key for a protected server.
`QDRANT_PATH`	`/data/qdrant`	Embedded storage path (mount a volume here).
`COLLECTION_NAME`	`cc_memory`	Qdrant collection.
`EMBEDDING_PROVIDER`	`local`	`local` (FastEmbed) or `openai`.
`EMBEDDING_MODEL`	`BAAI/bge-small-en-v1.5`	Model for the chosen provider.
`EMBEDDING_QUERY_PREFIX` / `EMBEDDING_PASSAGE_PREFIX`	(empty)	Instruction prefixes; set `"query: "` / `"passage: "` for the e5 family. See `eval/`.
`OPENAI_API_KEY` / `OPENAI_BASE_URL`	(unset)	For `openai` provider.
`CC_MEM_CATEGORIES`	(built-in)	JSON `{domain:[sub,...]}` to override the taxonomy.
`CC_MEM_STRICT_CATEGORIES`	`0`	`1` = reject unknown categories instead of warning.

Shared memory across machines/people

Run one Qdrant server (e.g. on a box everyone can reach) and point every client at it:

docker compose up -d qdrant           # from this repo
# then in each client's mcp config:
#   -e QDRANT_URL=http://<host>:6333

Everyone using the same QDRANT_URL + COLLECTION_NAME shares one memory. Keep the same EMBEDDING_PROVIDER/EMBEDDING_MODEL across clients — vectors from different models aren't comparable.

Run without Docker (from source)

python -m venv .venv && . .venv/bin/activate   # Windows: .venv\Scripts\activate
pip install -e .
# point at your Qdrant (omit for embedded local-file) and run:
QDRANT_URL=http://YOUR_QDRANT_HOST:6333 cc-mem-mcp     # stdio MCP server

Wire it into Claude Code with the venv's cc-mem-mcp executable as the command, passing QDRANT_URL / COLLECTION_NAME / EMBEDDING_MODEL via env (see examples/).

Automatic capture (PostCompact hook)

Copy a template from hooks/, set your QDRANT_URL, and register it in .claude/settings.json so every compaction is captured with no manual step. See hooks/README.md.

Push a v* tag and the bundled GitHub Actions workflow builds and publishes ghcr.io/<owner>/cc-mem-mcp — no secrets to set up:

git tag v0.1.0 && git push origin v0.1.0

Then anyone replaces OWNER in the examples/ .mcp.json with your GitHub owner and they're running the same memory server.

Multilingual note

The default embedding model is English-centric. For non-English content set a multilingual model, e.g.:

EMBEDDING_MODEL=sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2

Changing the model changes the vector dimension — use a fresh COLLECTION_NAME (or re-index) when you switch.

Notes

MCP is stdio JSON-RPC — the client launches the server per session with docker run -i; it is not a long-running HTTP service.
All logs go to stderr; stdout is reserved for the protocol.
Switching embedding models changes the vector dimension. Use a fresh COLLECTION_NAME (or re-index) when you change models.

License

MIT — see LICENSE.

Available Tools

7 tools

memory_categoriesA

List the active category taxonomy (domains and their sub-categories).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior2/5

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

The description only says 'List', implying a read operation, but no annotations are provided. It does not disclose any behavioral traits such as caching, permissions required, or whether initialization is needed, leaving gaps for the agent.

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?

One concise sentence that front-loads the key information: listing active category taxonomy. Every word is necessary, no fluff.

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?

Given the simplicity of the tool (no parameters, output schema present), the description is complete enough for an agent to understand what it does. It explains what the taxonomy contains (domains and sub-categories).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description does not need to add parameter semantics, and it correctly omits any parameter information.

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?

Description clearly states the tool lists the active category taxonomy including domains and sub-categories, with a specific verb and resource. It distinguishes from siblings like memory_delete or memory_stats, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The purpose is implied, but there is no mention of context or exclusions, leaving the agent to infer usage from the description alone.

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

memory_deleteA

Delete a stored fact by its id (as returned by memory_store/memory_find).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It conveys a destructive action ('delete') but does not disclose side effects, reversibility, or error behavior. Basic transparency is achieved but not enriched beyond the minimal.

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?

The description is a single, complete sentence that efficiently conveys all necessary information. It is front-loaded with the action and resource, with no redundant or superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one required parameter, output schema exists), the description covers the core usage. It explains what to delete and how to obtain the identifier. Minor gaps exist (e.g., no mention of case when id doesn't exist), but overall it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must add meaning. It explains that the 'id' parameter is 'as returned by memory_store/memory_find', which provides crucial sourcing context beyond the schema's 'Id' title. This sufficiently compensates for the lack of schema documentation.

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?

The description clearly states the verb 'delete' and the resource 'a stored fact', specifying the identification method via 'id'. It also clarifies the provenance of the id by referencing memory_store/memory_find, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when one wants to delete a stored fact and has its id. However, it lacks explicit guidance on when not to use this tool (e.g., if id is missing) and does not compare to sibling tools like memory_ingest or memory_store.

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

memory_findA

Retrieve relevant facts by meaning (semantic search).

Call this at the start of a task instead of relying on the compaction summary. Narrow with category (code.connections, or a whole domain like code) and/or project. Returns the top matches with a similarity score.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes
`project`	No
`category`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It explains that it performs semantic search, returns top matches with similarity score, and can be narrowed by category/project. It does not disclose any destructive aspects or side effects, but it is a read operation and sufficient for the tool's purpose.

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?

The description is very concise: two sentences with clear front-loading of the core action. Every word adds value, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool, the description covers when to use, what it returns (top matches with similarity score), and how to narrow results. The presence of an output schema (not shown) reduces the need to describe return format. It is complete enough for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining the query parameter for semantic search, the category parameter with examples ('code.connections' or 'code'), and the project parameter for narrowing. Limit is implied by 'top matches'. This provides conceptual clarity beyond the schema.

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?

The description clearly states 'Retrieve relevant facts by meaning (semantic search)', which is a specific verb+resource. It distinguishes from siblings like memory_store (store) and memory_categories (list categories) by focusing on retrieval via semantic search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Call this at the start of a task instead of relying on the compaction summary', providing a clear use case. It also mentions narrowing by category and project, but does not specify when not to use or list alternatives explicitly.

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

memory_ingestA

Capture Claude Code's OWN compaction summaries from disk into memory.

This is the primary write path: instead of tagging facts by hand, it reads the transcript(s) Claude Code writes to ~/.claude/projects/<slug>/*.jsonl, finds every compaction summary, and stores each of the summary's numbered sections (Primary Request, Files and Code Sections, Errors and fixes, Pending Tasks, ...) as categorized, dedup'd chunks. Safe to run repeatedly — unchanged chunks re-map to the same id, so nothing piles up and nothing is lost across compaction generations.

project: restrict to one project slug (the transcript folder name). Omit to scan all projects. session_path: ingest a single .jsonl transcript instead of scanning.

ParametersJSON Schema

Name	Required	Description	Default
`project`	No
`session_path`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses key behaviors: reads from a specific path (~/.claude/projects/<slug>/*.jsonl), extracts compaction summaries, stores categorized chunks, and is idempotent. It also mentions deduplication and that nothing is lost across generations. Minor omission: no mention of error handling or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a bold purpose statement, followed by mechanism, safety note, and parameter details. It is front-loaded with the core function. While slightly verbose, it contains no redundant sentences. Could be tightened by merging the safety note with the mechanism paragraph.

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 tool with only 2 optional parameters, the description is thorough. It covers purpose, mechanics, idempotency, and parameter usage. An output schema exists, so return format is not required in description. No gaps evident for the complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Given 0% schema description coverage, the description fully compensates. It explicitly documents both parameters: 'project' restricts to one slug (or scans all if omitted), 'session_path' ingests a single file instead of scanning. This adds critical meaning beyond the raw schema types.

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?

The description starts with a clear action: 'Capture Claude Code's OWN compaction summaries from disk into memory.' It explains the resource (compaction summaries from transcripts) and the verb (ingest/capture). It distinguishes itself from siblings by being the 'primary write path' and describes a unique mechanism (reading .jsonl files) not shared by other memory tools like memory_store or memory_find.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidance on when to use the tool: it is safe to run repeatedly due to idempotency ('unchanged chunks re-map to the same id'). It explains parameter usage with clear instructions: omit 'project' to scan all, use 'session_path' for single file. However, it lacks explicit 'when not to use' or comparison with alternatives like memory_store for direct storage.

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

memory_initA

Create the FIRST STATE for a project and wire Claude Code to use memory.

Call this once at the start of working on a repo (or to refresh — it's idempotent). It:

Scans the repo into a categorized project.* baseline (overview, stack, structure, commands, connections, git, docs).
Folds in current context: ingests any existing compaction summaries for this repo's Claude Code session(s).
Installs a managed memory block in the project CLAUDE.md so the agent knows to query (memory_find) and rely on automatic updates.

root: repo path (defaults to the server's working directory). When running in Docker, mount the repo and pass its in-container path here. install_hooks: also add SessionStart/PostCompact hooks to ~/.claude/settings.json.

ParametersJSON Schema

Name	Required	Description	Default
`root`	No
`project`	No
`install_hooks`	No
`install_claude_md`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior5/5

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

No annotations are provided, so the description fully carries the burden. It discloses that the tool scans the repo, folds in compaction summaries, and installs a managed memory block. It also notes idempotency and the optional installation of hooks, giving a comprehensive view of side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately concise and well-structured with bullet points and parameter explanations. It front-loads the main purpose. Slightly verbose with the bullet lists, but clear and organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 4 parameters, no annotations, but an output schema exists. The description covers the initialization workflow, idempotency, and main side effects. It explains two parameters fully but leaves two undocumented. Overall, it's adequate for an initialization tool but could be more exhaustive.

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 0%, so the description must compensate. It explains 'root' (repo path, defaults to working directory, Docker hint) and 'install_hooks' (adds hooks to settings.json). However, 'project' and 'install_claude_md' are not described, leaving gaps.

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?

The description clearly states the tool creates the first state for a project and wires Claude Code to use memory. It specifies the verb 'Create' and the resource 'FIRST STATE', and distinguishes itself from sibling tools like memory_find or memory_store by focusing on initialization.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Call this once at the start of working on a repo (or to refresh — it's idempotent).' This provides clear context for when to use the tool. However, it does not explicitly mention when not to use it or directly compare with siblings.

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

memory_statsA

Report collection size, storage backend, and embedding configuration.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Without annotations, the description partially suggests read-only behavior via 'Report' but does not explicitly state safety, side effects, or authentication needs. For a simple zero-parameter tool, this is minimal but not fully transparent.

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?

The description is a single sentence with no wasted words, front-loaded with the verb 'Report,' making it immediately clear.

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 simple reports tool with an output schema, the description covers the key reported items adequately. No missing context needed for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema is fully covered. The description adds meaning by listing what is reported (collection size, backend, embedding config), which is helpful beyond an empty schema.

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?

The description clearly states the tool reports collection size, storage backend, and embedding configuration. It uses a specific verb and resource, distinguishing it from sibling tools like memory_delete or memory_find.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for obtaining memory statistics but provides no explicit when or when-not guidelines, nor does it mention alternatives among sibling tools.

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

memory_storeA

Persist ONE durable fact to long-term memory (write-through).

Call this the moment a fact worth surviving compaction appears — do NOT wait for the conversation to be summarized. One call = one atomic fact.

category is domain.sub. Built-in taxonomy: code.rules conventions, constraints, do/don't agreed this session code.workflow current procedure/steps, what's done, what's pending code.os OS, shell, tool versions, paths, env vars code.connections hosts / SSH / ports / domains / services / DBs in use code.files files changed, with absolute paths code.issues unresolved bugs / blockers business.goal the business problem being solved, expected outcome business.decision business decisions + rationale business.constraint requirements, limits, deadlines, stakeholders business.state where we are in the business flow

project: optional slug to scope the fact to one project/repo. tags: optional keywords for later filtering. source: optional origin note (e.g. a file path or URL).

ParametersJSON Schema

Name	Required	Description	Default
`tags`	No
`source`	No
`content`	Yes
`project`	No
`category`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Reveals write-through behavior and durability, but lacks details on idempotency, concurrency, or what happens on duplicate content. Additional behavior like error states or consistency is not addressed.

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 purpose and usage guidelines, followed by structured taxonomy and optional parameters. Every sentence adds value without redundancy. Efficient paragraph breaks enhance readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists (assumed adequate), so description does not need to detail return values. Covers required parameters and category taxonomy comprehensively. Optional parameters are briefly noted, which suffices for a single-fact tool. Minor gap: does not mention error handling or response format.

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 0%, making description the primary source. The category parameter is extensively documented with a built-in taxonomy. Other parameters (content, project, tags, source) receive only brief mentions ('the fact', 'optional slug', 'optional keywords', 'optional origin note'), lacking examples or constraints.

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?

The description clearly states the tool persists a single durable fact to long-term memory (write-through). It specifies 'ONE' and 'atomic fact', distinguishing it from batch operations like memory_ingest. The taxonomy for category is detailed, making resource and action clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use: 'the moment a fact worth surviving compaction appears' and 'do NOT wait for conversation summary.' Implicitly distinguishes from siblings by emphasizing single facts, though not naming alternatives like memory_ingest for bulk.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jul 6, 2026
- First observedmemory_categories
- First observedmemory_delete
- First observedmemory_find
- First observedmemory_ingest
- First observedmemory_init
- First observedmemory_stats
- First observedmemory_store

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: categories listing, deletion, semantic search, bulk ingestion from disk, initialization of project memory, stats reporting, and single-fact storage. No overlap between them.

Naming Consistency4/5

All tools follow the 'memory_' prefix. Most use verb forms (delete, find, ingest, init, store) but two use nouns (categories, stats). The pattern is mostly consistent with minor deviation.

Tool Count5/5

With 7 tools covering initialization, ingestion, storage, retrieval, deletion, categories, and statistics, the count is well-scoped for a memory management server. Each tool earns its place.

Completeness4/5

Core CRUD operations are covered (store, find, delete) along with initialization and bulk ingestion. Minor gaps like an explicit update or listing all facts are missing but can be worked around.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mifactory-agent-memory C
io.github.mifactory-bot
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Knowledge & Memory Autonomous Agents Agent Orchestration
22
MemoryRouter A
ai.memoryrouter
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Knowledge & Memory Search
101
memory
com.lodekeep
Portable memory for AI agents: capture once, recall across Claude, Cursor, and any MCP client.
Knowledge & Memory File Systems
1
mcpOAuth
ai.butlerbrain
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
Knowledge & Memory RAG Systems Workplace & Productivity
2

Related MCP Servers

RememberMe
Knowledge & Memory Vector Databases Search
JoeXie
F
license
A
quality
D
maintenance
Dual-mode tool providing long-term memory management for Claude Code and MCP clients, with semantic search and user/session isolation via Qdrant.
Updated 5 months ago (2026-04-14 01:28 UTC)
6
7
-
Mnemoverse Memory
Knowledge & Memory Search
mnemoverse
A
license
A
quality
A
maintenance
Persistent long-term memory for AI agents — semantic recall across Claude, Cursor, ChatGPT & MCP.
Updated 3 days ago (2026-09-03 12:12 UTC)
10
519
21
MIT
Unforget MCP Serverofficial
Knowledge & Memory RAG Systems
unforget-ai
A
license
Not graded
quality
C
maintenance
Long-term memory for Claude Code, Cursor, and MCP clients with zero-config embedded PostgreSQL. Stores and retrieves facts, preferences, and decisions using 4-channel semantic, BM25, entity, and temporal search with cross-encoder reranking.
Updated 5 months ago (2026-03-30 11:03 UTC)
1
Apache 2.0
semantic-memory
Knowledge & Memory RAG Systems
GFYURI
A
license
Not graded
quality
C
maintenance
Persistent memory with semantic search for Claude and MCP-compatible clients, storing context that survives conversations and can be retrieved intelligently.
Updated 10 months ago (2025-10-29 03:59 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/NguyenSen/cc-mem-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

cc-mem-mcp

Lifecycle: init → auto-update → query

Tools

Capture: keeping compactions losslessly

Quick start (Docker)

Configuration

Shared memory across machines/people

Run without Docker (from source)

Automatic capture (PostCompact hook)

Publish the image (to share with others)

Multilingual note

Notes

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Unforget MCP Serverofficial

Latest Blog Posts

MCP directory API