cc-mem-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 4.2/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![cc-mem-mcp MCP server](https://glama.ai/mcp/servers/NguyenSen/cc-mem-mcp/badges/card.svg)](https://glama.ai/mcp/servers/NguyenSen/cc-mem-mcp)

Score Badge

Copy to your README.md:

[![cc-mem-mcp MCP server](https://glama.ai/mcp/servers/NguyenSen/cc-mem-mcp/badges/score.svg)](https://glama.ai/mcp/servers/NguyenSen/cc-mem-mcp)

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