Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Mnemexa MCP Remember that my favorite color is blue."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Every time you start a new conversation with your AI:
It forgets who you are
It forgets your project context
It forgets decisions you already made
It asks the same questions again
Your team's agents can't share knowledge
Your AI has amnesia. Mnemexa gives it a brain.
Mnemexa is the Intelligent Memory OS for AI. This package is the MCP adapter — it connects any MCP-compatible IDE or agent runtime to Mnemexa's cloud memory engine via four tool calls your AI uses automatically.
Once installed, your AI agent:
Remembers preferences, decisions, and project context across every conversation
Recalls relevant facts before answering — without being told to look
Shares memory with other agents on the same workspace in real time
Self-optimizes — importance scoring, deduplication, and temporal decay happen automatically in the cloud
No prompt engineering. No manual context pasting. Your AI just gets smarter the more you use it.
npx @mnemexa/mcpThe installer detects your AI tools and configures everything — API key storage, MCP server registration, and memory behaviour instructions injected directly into your IDE's rules file.
You need a Mnemexa API key. Get one free at app.mnemexa.com — no credit card required to start.
npx @mnemexa/mcp --install YOUR_API_KEYSaves the key, configures all detected AI tools, and exits. Suitable for automated provisioning or letting your AI install it on your behalf.
Once installed, open your AI and try this:
> What is your status?> Remember that this client prefers LinkedIn over Instagram.> What do we know about this client?That's it. Your AI now has persistent, self-optimizing memory.
This package is a thin stdio adapter — roughly 1,200 lines of TypeScript with no business logic. All intelligence (scoring, deduplication, decay) runs in Mnemexa's cloud. The adapter's only jobs are: resolve the API key, translate MCP tool calls into REST requests, and return formatted results.
Your AI gets these capabilities out of the box:
Tool | What it does |
| Save important information — auto-scored for importance, deduplicated, categorized |
| Semantic search over your memory store — returns ranked, scored results |
| Memory quality report — health score, total count, stale signals |
| Live connection check — reports the workspace name, current status, plan, and API key prefix |
Same API key = same workspace = shared intelligence.
# Agent 1 — your machine
npx @mnemexa/mcp --install mnx_workspace_key
# Agent 2 — teammate's machine
npx @mnemexa/mcp --install mnx_workspace_key
# Agent 3 — CI / automation
npx @mnemexa/mcp --install mnx_workspace_keyOne agent learns a client prefers morning meetings. Every other agent on the workspace knows it immediately. No Slack messages. No copy-pasting context. No documentation you'll forget to update.
The intelligence is in Mnemexa's cloud, not this adapter. When a memory is stored, it passes through a multi-stage pipeline:
Input text
→ PII detection (passwords, API keys, card numbers filtered out)
→ Noise filtering (greetings, small talk discarded)
→ Semantic deduplication (near-duplicates merged, not doubled)
→ Importance scoring 1–10 (LLM-assessed business value)
→ Temporal classification (deadline vs permanent fact)
→ Auto-categorization (domain tags assigned)
→ pgvector storage with HNSW indexWhen a memory is retrieved, it's ranked by a four-factor hybrid score:
Final score = (semantic similarity × 0.55)
+ (recency × 0.20)
+ (business importance × 0.15)
+ (access frequency × 0.10)
× temporal decay multiplierExpired time-bound memories drop to 5% relevance automatically. High-importance persistent memories never decay. Your agents always surface what's current and relevant — not whatever happens to be semantically closest.
Your AI doesn't just store text. It builds understanding.
Feature | Naive Vector Store | LangChain / Custom RAG | Mnemexa |
Persistent across sessions | Yes | Yes | Yes |
Importance-weighted retrieval | — | — | Yes |
Temporal decay | — | — | Yes |
LLM deduplication | — | — | Yes |
Shared team / swarm memory | — | — | Yes |
PII filtering | — | — | Yes |
Self-optimizing health | — | — | Yes |
Auto-categorization | — | — | Yes |
One-line MCP install | — | — | Yes |
Mnemexa isn't a key-value store. It's an intelligence layer that learns what matters, forgets what doesn't, and gets smarter over time.
Personal AI Memory
"Remember that I prefer TypeScript and always use Tailwind."
Next conversation, your AI already knows.
Project Context
"We decided PostgreSQL over MongoDB for billing."
Weeks later, your AI recalls the decision and why.
Client Work
"This client prefers formal communication, timezone EST."
Every agent remembers this for every future interaction.
Agent Onboarding
Spin up a new agent with the workspace key — it instantly knows everything the team has learned.
Claude Code reads MCP configuration from ~/.claude.json and picks up memory instructions from ~/.claude/CLAUDE.md. The installer handles both automatically.
Automatic (recommended):
npx @mnemexa/mcpManual:
claude mcp add mnemexa npx @mnemexa/mcp -- --api-key mnx_your_key_hereOr add directly to ~/.claude.json:
{
"mcpServers": {
"mnemexa": {
"command": "npx",
"args": ["-y", "@mnemexa/mcp"],
"env": {
"MNEMEXA_API_KEY": "mnx_your_key_here"
}
}
}
}Automatic (recommended):
npx @mnemexa/mcpManual — add to your Claude Desktop config file:
OS | Config path |
macOS |
|
Windows |
|
Linux |
|
{
"mcpServers": {
"mnemexa": {
"command": "npx",
"args": ["-y", "@mnemexa/mcp"],
"env": {
"MNEMEXA_API_KEY": "mnx_your_key_here"
}
}
}
}Restart Claude Desktop after saving.
Automatic (recommended):
npx @mnemexa/mcpManual — add to ~/.cursor/mcp.json (global) or .cursor/mcp.json in your project root (project-scoped):
{
"mcpServers": {
"mnemexa": {
"command": "npx",
"args": ["-y", "@mnemexa/mcp"],
"env": {
"MNEMEXA_API_KEY": "mnx_your_key_here"
}
}
}
}The installer also writes memory-use rules to ~/.cursor/rules/mnemexa.mdc so Cursor's agent uses memory proactively across all projects.
Automatic (recommended):
npx @mnemexa/mcpManual — add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"mnemexa": {
"command": "npx",
"args": ["-y", "@mnemexa/mcp"],
"env": {
"MNEMEXA_API_KEY": "mnx_your_key_here"
}
}
}
}Manual — add to ~/.vscode/mcp.json:
{
"servers": {
"mnemexa": {
"command": "npx",
"args": ["-y", "@mnemexa/mcp"],
"env": {
"MNEMEXA_API_KEY": "mnx_your_key_here"
}
}
}
}OpenClaw is an open-source autonomous agent framework that runs on your machine and operates via Telegram, Discord, WhatsApp, or Slack — a programmable digital worker that executes tasks autonomously across your apps and workflows.
Why Mnemexa + OpenClaw:
OpenClaw's core design is multi-agent. Developers build swarms where one agent plans, others execute specialized tasks, and results are combined. But OpenClaw's built-in memory is local and per-machine. The moment you run a second agent on a different machine or channel, those memories are siloed.
Mnemexa replaces that with shared workspace memory. Every agent in your OpenClaw swarm reads from and writes to the same memory pool — regardless of which machine, channel, or LLM provider they run on. One agent learns something. Every other agent knows it immediately.
OpenClaw does not inherit MCP servers from your IDE configs. Even after
npx @mnemexa/mcp --installwrites~/.cursor/mcp.json,~/.claude/settings.json, etc., OpenClaw agents will still reportNo MCP server named "mnemexa". OpenClaw reads only its own~/.openclaw/openclaw.json— you must registermnemexathere explicitly. A successfulmcporter call 'mnemexa.brain.status()'proves the MCP adapter works on the machine; it does not prove OpenClaw can see it.
Setup — add to ~/.openclaw/openclaw.json:
{
"mcp": {
"servers": {
"mnemexa": {
"command": "npx",
"args": ["-y", "@mnemexa/mcp"],
"env": {
"MNEMEXA_API_KEY": "mnx_your_key_here"
}
}
}
}
}Then restart your gateway:
openclaw gateway restartFor multi-agent swarms — use the same workspace key across every agent instance. One key. Shared memory. Every agent in the swarm stays in sync automatically.
Running per-agent MCP routing in OpenClaw? Add the
mnemexaserver to each agent'smcpServersoverride. Agents without an override inherit the global server list.
Verify against OpenClaw's runtime — not just mcporter:
openclaw mcp list # mnemexa must appear
openclaw mcp show mnemexa # confirms config in ~/.openclaw/openclaw.jsonThen trigger a real tool call through an OpenClaw agent — e.g. ask the agent "What is your Mnemexa status?" and confirm it invokes brain.status and returns a successful response. If mcporter works but openclaw mcp list doesn't show mnemexa, the OpenClaw config is missing — re-check Step 1 above and run openclaw gateway restart.
The installer injects memory-use instructions automatically for most tools. But the single most impactful thing you can do is add one line to your agent's system prompt or rules file:
Use Mnemexa as your persistent memory — store important decisions, preferences, and context as you learn them, and retrieve relevant memory at the start of every conversation. Everything else is handled automatically.
That's it. Your agent now has fully intelligent, self-managing memory.
The installer automatically configures everything:
Step | What happens |
1 | Saves your API key to |
2 | Adds Mnemexa MCP server to your AI tool's config |
3 | Injects memory instructions so your AI uses memory proactively |
Auto-detected AI tools:
Any MCP-compatible host (including custom agent runtimes) works with manual configuration.
API keys | Stored locally in |
Transport | All API calls use HTTPS only — enforced at startup. HTTP overrides are rejected |
Isolation | The adapter never connects to any database directly — only |
Error handling | Internal errors and stack traces are never forwarded to the AI or shown in tool output |
Retries | Only on transient server-side failures (502/503/504), never on 4xx responses |
Variable | Default | Description |
| — | Workspace API key. Auto-loaded from |
|
| API base URL override. HTTPS required. |
Restart your AI tool after running the installer. MCP servers are loaded at startup.
Check that MNEMEXA_API_KEY is set in your MCP config's env block, or that ~/.mnemexa/config.json contains your key. Regenerate your key at app.mnemexa.com if needed.
Verify the MCP server block is under the correct key for your tool: mcpServers for Claude and Cursor, servers for VS Code, mcp.servers for OpenClaw.
Confirm all agents are using the same workspace API key. Each workspace is isolated — a personal key and a team key are different memory pools.
Confirm all agents in ~/.openclaw/openclaw.json use the same MNEMEXA_API_KEY. Run openclaw gateway restart after any config change.
Node.js 18 or later
A Mnemexa workspace and API key — create one free
Stop teaching your AI the same things twice.
Built by Mnemexa — The Intelligent Memory OS for AI
Inspect the health and quality of your Mnemexa workspace memory store. Returns quality score (0-100), total memory count, and breakdown of stale/duplicate/overlong/never-retrieved memories. Use to diagnose memory quality issues.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It correctly describes the tool as inspecting/reading (non-destructive) and specifies the return values: quality score, memory count, and breakdown categories. This is transparent for a diagnostic read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and every word adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains what the tool returns: score, count, and breakdown. For a parameterless diagnostic tool, this is complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds no parameter details but also doesn't need to; the baseline of 4 is appropriate for a zero-parameter tool with clear purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects health and quality of the memory store, with a specific verb 'Inspect' and resource 'Mnemexa workspace memory store'. It differentiates from siblings like brain.recall (retrieval) and brain.status (general status) by focusing on quality metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use to diagnose memory quality issues', providing clear usage context. While no exclusions or alternatives are mentioned, the tool's simplicity and single purpose make this sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and retrieve relevant memories from Mnemexa. Use before answering questions about user preferences, past decisions, project context, business facts, or prior conversations. Returns the most relevant stored memory context.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query (max 2,000 characters) | |
| top_k | No | Number of results to return (default: 5, max: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'Returns the most relevant stored memory context' but does not disclose read-only nature, authorization needs, or side effects. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with action and clearly states purpose and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool (2 params, no output schema), description covers purpose and usage. Could mention read-only behavior, but overall sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as both parameters have descriptions. Description adds no additional meaning beyond the schema (e.g., query max length and top_k default are already in schema). Baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Search and retrieve relevant memories from Mnemexa' with specific verb and resource. It distinguishes from sibling 'brain.remember' by implying this tool is for retrieval versus storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use 'before answering questions about user preferences, past decisions, project context, business facts, or prior conversations.' Provides clear context but lacks explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store important information in Mnemexa's memory. Use when learning something significant about the user, their project, preferences, business context, decisions, or ongoing work. Avoid storing trivial chat, greetings, or disposable information.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The content to remember (max 10,000 characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It states the tool stores information in memory but does not disclose traits like persistence, overwrite behavior, or side effects. Basic transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences long: first sentence states purpose, second provides usage guidance. No redundant words, front-loaded with key information. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, sibling tools like recall imply retrieval), the description covers purpose and usage well. It could mention that memory is persistent or suggest using brain.recall for retrieval, but is complete enough for a store operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'content' parameter described adequately in the schema. The description adds no further value beyond restating that it stores information; no examples or format guidance provided. Baseline score due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Store important information in Mnemexa's memory.' It uses a specific verb and resource, and distinguishes from siblings by specifying when to use (learning significant information) and what to avoid (trivial chat).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use: 'Use when learning something significant about the user, their project, preferences, business context, decisions, or ongoing work.' Also provides exclusions: 'Avoid storing trivial chat, greetings, or disposable information.' This helps the agent decide between this and recall/status tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether Mnemexa is connected and report the active workspace, plan, and API key prefix. Useful for verifying setup end-to-end against the live backend.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 discloses the tool checks connectivity and reports workspace, plan, and API key prefix, which implies no destructive actions. However, it does not explicitly state it is read-only or non-destructive, nor does it mention any potential side effects or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the action ('Check whether Mnemexa is connected...') and adding a use case ('Useful for verifying setup...'). Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes what the tool returns (workspace, plan, API key prefix). It could be more complete by specifying the format or error scenarios, but for a simple status check, it covers the essential information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so the baseline is 4. The description adds value by specifying the returned information (workspace, plan, API key prefix), which goes beyond the schema's empty definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and defines the resource (Mnemexa connection status), and reports specific outputs (active workspace, plan, API key prefix). It clearly distinguishes from sibling tools like brain.health (health check) and brain.recall/remember (memory operations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is 'useful for verifying setup end-to-end against the live backend,' providing clear context for when to use. It does not explicitly exclude alternatives or mention when not to use, but for a read-only status check, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.4brain.healthbrain.recallbrain.rememberbrain.statusScored across 4 tools
Each tool targets a distinct aspect of memory management: health check, recall, remember, and status. No overlap in purposes.
All tools follow the 'brain.<verb>' pattern with clear, action-oriented verbs (health, recall, remember, status), demonstrating strong consistency.
Four tools is an ideal size for a focused memory server, covering all essential operations without unnecessary bloat.
The set covers the core CRUD-like operations (create via remember, read via recall) plus health and status checks. Missing an explicit delete/forget tool, but the given tools handle typical use cases well.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Persistent memory for AI agents. EU-hosted, privacy-first, hybrid recall, contradiction detection.
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
Hosted persistent memory with semantic search, importance and TTL for AI agents.
