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 scanned for sensitive patterns (API keys, passwords, tokens) before sending to Cloud. If detected, the write is blocked and findings are returned with a hint on how to proceed. For chat:* spaces, similar existing memories are checked automatically and surfaced as conflicts in the response. Use check_conflicts to override. 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:).

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.