Evermemos Mcp

Name: Evermemos Mcp
Author: tt-a1i

@tt-a1i

代码仓库主页

关于 Evermemos Mcp

Universal long-term memory layer for AI coding assistants, powered by EverMemOS.

#memory #knowledge #long-term-memory #coding-assistant #evermemos #recall #context

基本信息

分类

其他

运行时

python

传输方式

stdio

发布者

tt-a1i

提交者

tt-a1i

配置

使用下面的配置,将此服务器添加到你的 MCP 客户端。

{
  "mcpServers": {
    "evermemos-mcp": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "evermemos-mcp@latest"
      ],
      "env": {
        "EVERMEMOS_API_KEY": "<YOUR_API_KEY>",
        "EVERMEMOS_USER_ID": "mcp-user"
      }
    }
  }
}

工具

List MCP-visible memory spaces that this server can route and recover. Call this first to discover which space_id values are available before using other memory tools. Each space isolates memories by project or topic (e.g. coding:my-app, study:ml-notes, chat:preferences). Note: some native EverMemOS Cloud spaces created outside the MCP naming and catalog flow may not appear here. If no spaces exist yet, create one by calling remember with a new space_id and description.

Store information in long-term memory within a specific space. Use this proactively to save architecture decisions, user preferences, project conventions, bug solutions, and key context. Content is queued for AI extraction and becomes searchable only after upstream processing completes. For important writes, prefer remember(include_status=true) so the write-after status check runs immediately. Use request_status, recall, or briefing to distinguish queued, provisional, fallback, and searchable states. Set flush=true at end of session or topic switch; flush=false during ongoing work. Provide a description when creating a new space for the first time.

Check the async processing status for a prior remember request. Use this when remember returned a request_id and you need to know whether extraction is still queued or has been reported complete by upstream. Check success/error first, then interpret lifecycle.state.

Search for relevant memories in one or more spaces. Use this when you need context about prior decisions, preferences, conventions, or anything discussed in previous sessions. Returns matching memories with traceable citations (memory_type, snippet, timestamp, relevance score). Also reports whether current results are searchable, provisional, or fallback. Pending signals depend on upstream pending_messages support and may be absent even while extraction is still in progress. If you need chronological review, delete verification, or a complete timeline, prefer fetch_history instead of relying on relevance-ranked recall alone. If space_id and space_ids are both omitted, auto-detected from git remote (coding:<repo-name>).

Get a structured context briefing for a memory space. Call this at the start of a new session to restore high-value context quickly. Returns: user profile, recent episodes, key facts, and foresights. When formal profile memories are unavailable, briefing may surface explicit fallback metadata and label it as such. This is the fastest way to catch up on the most important currently available context in a space.

Request deletion of specific memories from a space. Use fetch_history or recall to identify targets first — results may include a parent_id (memcell ID) which is the effective delete key used by EverMemOS Cloud. The server resolves parent_id automatically when available (recent 100 items per type). Verify deletion afterwards with fetch_history; some IDs may remain unmatched if the memory was already deleted or outside the resolution window.

Page through historical memories in a space by memory_type. Useful for chronological timeline review when recall's relevance ranking is not sufficient, or when you need to browse all memories of a type. This is the primary tool for timeline review, pre-delete verification, and post-delete re-checks.

概览

What is Evermemos Mcp?

Evermemos Mcp is a long‑term memory server for AI coding assistants. It stores and retrieves context across sessions using the EverMemOS Cloud API, eliminating the need to re‑explain project details every session.

How to use Evermemos Mcp?

Get an API key from EverMemOS Cloud, then add the server to your MCP client configuration with the EVERMEMOS_API_KEY environment variable. Run via uvx evermemos-mcp@latest. Works with Claude Code, Cursor, Cline, Cherry Studio, OpenClaw, Gemini CLI, Aider, and any MCP‑compatible client.

Key features of Evermemos Mcp

Space isolation with domain:slug per project or topic
Multi‑space search across up to 10 spaces in one call
Sensitive content guard blocking API keys, passwords, tokens
Memory conflict detection in chat spaces
Lifecycle tracking: queued, provisional, fallback, searchable
Git auto‑detection infers space from remote repository name

Use cases of Evermemos Mcp

Store architecture decisions and recall them in a new session
Save personal preferences like UI theme and keybindings across chats
Keep cross‑session learning notes under a dedicated study space

FAQ from Evermemos Mcp

How does Evermemos Mcp differ from other memory MCP servers?

It offers space isolation, lifecycle tracking, sensitive content guard, conflict detection, multi‑space search, six retrieval strategies, and benchmark‑verified 60/60 recall with zero attribution errors.

What are the runtime requirements?

Python, uv (or uvx), and a valid EverMemOS Cloud API key set in the EVERMEMOS_API_KEY environment variable.

Where are memories stored?

All memories live on EverMemOS Cloud. There is no local persistence; the server is cloud‑first.

What does the `flush` parameter do on `remember`?

flush controls whether the write is immediately sent for extraction. Use false mid‑conversation and true at end of session or topic switch.

Is memory deletion instant?

No, cloud deletion is async and best‑effort. The server provides a verification workflow: confirm the target via fetch_history, call forget, then verify with fetch_history again.