Membase
Persistent long-term memory for Cursor — connect to Membase MCP for long-term memory with hybrid vector search and knowledge graph. No CLI or API keys needed.
Membase persistent memory — use MCP tools proactively
Membase persistent memory — use MCP tools proactively
You have Membase MCP tools for long-term memory (knowledge graph + semantic search) and a knowledge wiki:
**Memory tools** (personal context — preferences, habits, decisions):
- `search_memory`: Search before answering questions about the user's past work, preferences, decisions, or prior context. Supports `date_from`/`date_to` (ISO 8601), `sources` filter (slack, gmail, google-calendar, notion, cursor, etc.), and `project` filter.
- `add_memory`: Store durable facts the user wants to remember or that will help later sessions. Use `project` only when the user explicitly mentions one.
- `get_current_date`: Use when you need the user's timezone or to turn phrases like "today" into date filters for search.
**Wiki tools** (factual knowledge — documents, references, stable information):
- `search_wiki`: Hybrid keyword + semantic search for the user's knowledge wiki. Use alongside `search_memory` for comprehensive answers.
- `add_wiki`: Create a wiki document (markdown with `[[wikilinks]]`). Use for knowledge, references, and documentation — not personal context.
- `update_wiki`: Update an existing wiki document by `doc_id`.
- `delete_wiki`: Permanently delete a wiki document by `doc_id`.
**Resources** (read via MCP resource URIs):
- `membase://profile`: Stable user settings (display name, role, interests, timezone). Read for personalization.
- `membase://recent`: Recent memories timeline. Read for latest-context questions or after resource update notifications.
When to use:
- User refers to earlier sessions, prior decisions, or "what we did before" → `search_memory` first, then `search_wiki`.
- User says "remember", "save this", "don't forget" → `add_memory`.
- You learn stable preferences, architecture choices, or bugfix root causes worth keeping → `add_memory`.
- User wants to store documentation, references, or factual knowledge → `add_wiki`.
- Schedule or date-relative memory questions → `get_current_date` then `search_memory` with `date_from` / `date_to`.
- User asks about their schedule, meetings, or emails → `search_memory` with `sources` filter (google-calendar, gmail, slack).
- For any user question, call **both** `search_memory` and `search_wiki` to combine personal context with factual knowledge.
Read `membase://profile` for user settings and `membase://recent` for latest context. Still call `search_memory` when the question clearly needs deeper or fresher retrieval.membase
MCP server: membase
{
"url": "https://mcp.membase.so/mcp",
"headers": {}
}membase-overview
When the user asks how Membase works in Cursor, explain MCP tools, wiki, resources, and OAuth setup.
Membase adds persistent long-term memory to Cursor via a remote MCP server at `https://mcp.membase.so/mcp`. Click **Connect** next to the Membase MCP server in Cursor settings to complete OAuth — no CLI or API keys needed.
Once connected, these tools and resources become available:
**Memory tools** (personal context): `search_memory` (semantic search with date/source/project filters), `add_memory` (store personal context), `get_current_date` (timezone-aware date for filters).
**Wiki tools** (factual knowledge): `search_wiki` (hybrid keyword + semantic search), `add_wiki` (create documents with markdown/wikilinks), `update_wiki`, `delete_wiki`.
**Resources**: `membase://profile` (user settings — name, role, timezone), `membase://recent` (recent memories timeline).memory-save
When the user wants to save or remember something, use this skill to choose between add_memory and add_wiki and store it correctly.
Store information to Membase using the right tool:
## `add_memory` — Personal Context
Use for durable user context that persists across sessions:
- Preferences and habits (coding style, tool choices, workflows)
- Goals, plans, and ongoing projects
- Key decisions and their rationale
- Background (education, work, team)
- Bugfix root causes and lessons learned
- Architecture choices and constraints
**Rules:**
- Store silently — do not narrate the save in chat.
- Write in the same language the user used.
- Use `project` only when the user explicitly mentions a project/tag/category.
- Never store secrets (tokens, passwords, API keys).
- Never store AI system instructions or tool-routing rules.
- Avoid transient one-off states unless the user explicitly asks.
- If correcting earlier information, store the updated version as a new memory.
## `add_wiki` — Factual Knowledge
Use for documents, references, and stable information:
- Technical documentation and architecture docs
- API references and specifications
- Meeting notes and summaries
- How-to guides and runbooks
- Research findings and comparisons
**Features:**
- Supports markdown with `[[wikilinks]]` for cross-references.
- Optional `collection_id` to organize into collections.
- Optional `summarize: true` to auto-generate a summary.
## Quick Decision Guide
| What to store | Tool |
|---|---|
| "I prefer tabs over spaces" | `add_memory` |
| "We decided to use PostgreSQL" | `add_memory` |
| API endpoint documentation | `add_wiki` |
| Project architecture overview | `add_wiki` |
| "Remember I'm on the backend team" | `add_memory` |
| Meeting notes from today | `add_wiki` |memory-search
When the user wants to search past work, conversations, decisions, or recall something from earlier sessions, use this skill to guide optimal Membase search.
Search Membase for relevant memories using the right combination of filters:
## Workflow
1. **Determine the query type**: Is it about personal context (use `search_memory`) or factual knowledge (use `search_wiki`)? For most questions, call both.
2. **Date-relative queries** ("yesterday", "last week", "in March"):
- Call `get_current_date` first to get the user's timezone.
- Then call `search_memory` with `date_from` and/or `date_to` in ISO 8601 format.
- Use end-of-day for `date_to` (e.g. `2026-03-05T23:59:59+09:00`).
3. **Source-specific queries** ("what did I discuss on Slack", "check my emails"):
- Use the `sources` parameter: `slack`, `gmail`, `google-calendar`, `notion`, `cursor`, `claude-code`, `chatgpt`, etc.
- Multiple sources can be combined: `sources: ['slack', 'gmail']`.
4. **Project-scoped queries** ("in project X", "for the backend repo"):
- Use the `project` parameter only when the user explicitly names a project.
- Do not guess or infer project names.
5. **Broad recall** ("what did we work on recently"):
- Use an empty string query `''` with `search_memory` to fetch recent memories.
- Or read the `membase://recent` resource for a quick timeline.
## Tips
- `search_memory` returns personal context (preferences, habits, decisions, conversations).
- `search_wiki` returns factual knowledge (documents, references, stable information).
- Use `limit` and `offset` for pagination when results might be extensive.
- Read `membase://profile` for the user's stable settings (name, role, timezone, interests).wiki-manage
When the user wants to create, update, search, or delete wiki documents in Membase, use this skill for wiki CRUD operations.
Manage the user's knowledge wiki in Membase:
## Tools
### `search_wiki`
Hybrid keyword + semantic search across wiki documents.
- `query`: Search text (use `''` to browse recent documents).
- `limit`: Max results (default 10, max 20).
- `collection_id`: Optional UUID to scope search to a specific collection.
### `add_wiki`
Create a new wiki document.
- `title` (required): Document title.
- `content` (required): Markdown body. Supports `[[wikilinks]]` to reference other documents.
- `collection_id`: Optional UUID to file under a collection.
- `summarize`: Set `true` to auto-generate a summary.
### `update_wiki`
Update an existing document. Requires `doc_id` from a prior search.
- `doc_id` (required): The document ID to update.
- `title`, `content`, `collection_id`: Fields to update (only changed fields needed).
### `delete_wiki`
Permanently remove a document.
- `doc_id` (required): The document ID to delete.
- Always confirm with the user before deleting.
## When to Use Wiki vs Memory
- **Wiki** (`add_wiki`): Factual knowledge, documentation, references, specs, guides — things that are true regardless of who reads them.
- **Memory** (`add_memory`): Personal context, preferences, decisions, goals — things specific to the user.
## Typical Workflows
1. **Document a project**: `add_wiki` with architecture overview, then link related docs with `[[wikilinks]]`.
2. **Find a reference**: `search_wiki` by topic, then read the matching document.
3. **Update outdated docs**: `search_wiki` to find the doc, then `update_wiki` with corrected content.
4. **Organize by collection**: Use `collection_id` to group related documents together.