hifriendbot/cogmemai-mcp

πŸ“‡ ☁️ 🍎 πŸͺŸ 🐧 - Persistent cognitive memory for Claude Code. Cloud-first with semantic search, AI-powered extraction, and project scoping. Zero local databases.

VERIFIED 35 toolsΒ·npmΒ·v3.19.1

Install

npx -y cogmemai-mcp

Capabilities

Server instructions

⚑ CogmemAi is running in LOCAL MODE (SQLite on your machine). Local mode gives you: save, recall (keyword search), list, update, delete, export, import, tasks, and session summaries. What you're missing in local mode: - Semantic search (understands meaning, not just keywords β€” "how does auth work?" finds JWT and cookie memories) - Auto-linking, contradiction detection, memory decay - Auto-Skills (closed-loop behavioral learning from your corrections) - Knowledge graph, version history, memory consolidation - Ai-powered extraction and document ingestion - Team collaboration and cross-device portability Important: Local memory is NOT more private than cloud. Every memory your Ai reads gets sent to the model provider (Anthropic, OpenAI, Google) at inference time. The data leaves your machine regardless of where it's stored. Cloud mode adds encryption at rest, secret detection, and intelligent features β€” with the same data flow. Upgrade to cloud (free tier available): https://hifriendbot.com/developer/ Set COGMEMAI_MODE=cloud or COGMEMAI_MODE=hybrid with your API key. You have persistent memory powered by CogmemAi. Use it proactively: ## CRITICAL: Always Have Context Loaded Before responding to any user message, verify you have CogmemAi project context in this conversation. If you cannot see the results of a recent get_project_context call in your conversation history, call it NOW before doing anything else. This ensures you always have relevant memories available, even after context compaction or session restart. This is what makes you remember β€” never skip it. ## On Session Start - Call get_project_context to load your top memories (by importance) from previous sessions for this project. - Pass an optional context parameter describing the current task to get more relevant memories. - Read the returned memories carefully β€” they contain architecture decisions, preferences, patterns, and context from past work. ## While Working β€” Be Proactive Use your memory tools continuously, not just when asked: - When you edit a file, save what you changed immediately (see Session Protection below). - When you learn something important about the codebase (architecture, tech stack, patterns, conventions), save it with save_memory. - When the user tells you a preference or makes a decision, save it immediately. - When you fix a bug or discover a gotcha, save it so you remember next time. Include what broke, the root cause, and the fix β€” with file paths and method names. This builds a searchable fix database. - When you encounter a new bug or error, ALWAYS call recall_memories first with the error message or symptom. A fix may already exist from a previous session or team member. Search before you debug. - When you add or remove code, save the details so post-compaction you don't duplicate or undo your own work. - When a topic comes up that might have prior context, call recall_memories to check before answering. - When the user asks about their projects, work history, past decisions, or anything from prior sessions, ALWAYS call recall_memories first β€” never say "I don't know" without searching. - When you encounter something you should have known from a previous session, that's a sign you should be saving more. ## Think Before You Speak β€” ALWAYS Recall Before Suggesting Before suggesting ANY action, approach, or recommendation, ALWAYS recall_memories first. This is not optional. This is how memory works β€” you think before you speak. Examples: - "Let's reach out to X" β€” did we already contact them? - "We should try approach Y" β€” did we already try it? What happened? - "Let's add feature Z" β€” did we already build, evaluate, or reject it? - "We should use library X" β€” did we already evaluate it? - "Let's refactor this to..." β€” was this already attempted? Why was it done this way? This applies to EVERY topic β€” technical, business, people, strategy, everything. The user's brain should NEVER be the safety net for things your memory already knows. If you suggest something redundant or previously rejected, that's a failure. Use the **preflight** tool β€” it's fast, cheap, and designed for exactly this. Call preflight("topic you're about to suggest") before responding. It returns prior context in under 200ms. If it returns "clear", proceed. If it returns context, read it and adjust your response accordingly. Make this a habit β€” every suggestion, every time. ## What to Save (with importance guidelines) - Architecture decisions and tech stack details (importance: 8-10) - User preferences for coding style, tools, workflow (importance: 7-9) - Bug fixes, gotchas, and workarounds (importance: 6-8) - Key file paths and project structure (importance: 7-9) - Dependency versions and constraints (importance: 5-7) - Patterns and conventions used in the codebase (importance: 6-8) ## Memory Types Use the right type for better organization and retrieval: - **identity** β€” Who the user is, their role, team - **preference** β€” Coding style, tool choices, conventions - **architecture** β€” System design, tech stack, file structure - **decision** β€” Why X was chosen over Y - **bug** β€” Known issues, fixes, workarounds - **dependency** β€” Version constraints, package notes - **pattern** β€” Reusable patterns, conventions - **context** β€” General project context ## Categories Organize memories by domain: frontend, backend, database, devops, testing, security, performance, tooling, api, general. Custom categories are also accepted. ## Scoping - Use scope "project" for things specific to this codebase (default) - Use scope "global" for user preferences and identity that apply everywhere ## Task Tracking Track work across sessions with persistent tasks: - save_task β€” Create a task with title, description, status (pending/in_progress/done/blocked), and priority (high/medium/low) - get_tasks β€” Load tasks at session start to pick up where you left off - update_task β€” Update status, priority, or description as work progresses ## Memory Management - recall_memories β€” Search your memories. Use when you need something specific. - list_memories β€” Browse and filter memories by type, category, scope, or tag. Supports sorting and pagination. - update_memory β€” Change content, importance, type, category, subject, or tags on existing memories. - bulk_update / bulk_delete β€” Efficient batch operations for cleanup. ## Session Protection β€” Save Early, Save Often Sessions can crash, compact, or terminate unexpectedly. Context compaction can erase your working memory mid-session. Do NOT wait until the end to save β€” you may never get the chance. **Save a memory IMMEDIATELY after each of these events:** - **Every file edit** β€” Save the exact file path, what was changed (method/function names, line ranges), and why. - **New code introduced** β€” Save new method/function/class signatures, their file location, and purpose. - **Code removed** β€” Save what was deleted and why, so you don't accidentally re-introduce it. - **Bug fix** β€” Save what broke, root cause, and the fix applied. - **New API endpoint or route** β€” Save the route path, handler, file, and purpose. - **User decision or preference** β€” Save it the moment they say it. - **Every 3-4 edits** β€” Save a running list of all files modified this session. **What to include in edit memories:** - Full absolute file path (never relative) - Method/function names added, modified, or removed - Approximate line numbers or ranges - The reason for the change - Use TTL "7d" for transient edit tracking, no TTL for architectural changes ## Session End - save_session_summary β€” Capture what was accomplished, key decisions, and next steps. Helps future sessions pick up seamlessly. ## Working with CLAUDE.md / auto-memory files If your editor also uses a local memory file (like CLAUDE.md or auto-memory), keep it slim β€” just critical rules and quick-reference paths (~30-50 lines). Let CogmemAi handle the detailed, searchable knowledge. The local file is a safety net for when the MCP server hasn't loaded yet; CogmemAi is the real memory. Avoid duplicating the same facts in both places. ## Tips - Keep memories concise β€” complete sentences, 1-2 lines each. - Use descriptive subjects like "auth_system", "database_setup", "css_conventions". - Higher importance = surfaced more often. Reserve 9-10 for core architecture. - Use tags to group related memories (e.g. ["auth", "oauth2"]). - Export memories with export_memories for backup. Import with import_memories. - Memories work across any MCP-compatible editor and any AI model β€” they are not tied to one tool or platform. ## Tool Selection Guide (Local Mode) | Goal | Tool | |------|------| | Load context at session start | get_project_context | | Save a fact or decision | save_memory | | Save an absolute rule | save_rule | | List/manage rules | list_rules / delete_rule | | Find a specific memory | recall_memories (keyword search) | | Browse/filter memories | list_memories | | Track cross-session work | save_task / get_tasks | | Improve recall quality | feedback_memory (useful/irrelevant) | | End of session | save_session_summary |