memos-mcp-server
Click on "Install 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., "@memos-mcp-serverremember that the build script requires Node 18"
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.
memos-mcp-server
A small Python MCP server that bridges any MCP-compatible IDE (VS Code, Cursor, Claude Code) to a local MemOS instance, so notes you take in your editor land in the same knowledge base your AI agents read from.
Designed for the Animus Systems / Paperclip stack, where MemOS is already running in Docker and serving as the shared knowledge layer for ~50 Paperclip agents. Until now, knowledge written in human IDE sessions and knowledge written by agents lived in different worlds. This server closes that loop with one config line.
Why
Sequence of events from a real Paperclip session:
You tell Claude/Copilot in VS Code: "the accounts rename routine uses spaces around all dashes and 3-letter currency codes"
That fact is captured nowhere persistent — when the session ends, it's gone
Two days later your bookkeeping agent runs the routine, doesn't know the convention, gets it wrong, and you have to type the same explanation into a Paperclip issue description
With this MCP server, step 1 stores the fact into MemOS via memos_remember. The Paperclip agent-memory plugin's pre-run hook auto-injects the same MemOS scope into every agent run. The bookkeeping agent picks up the convention on its next heartbeat, no plugin changes required.
Related MCP server: Bruin
Tools
Tool | What it does |
| Store a memory. Auto-redacts credentials before sending. |
| Search MemOS, return ranked results with metadata. |
| Recent memories (default last 24 h), optional source filter. |
A startup health check pings MemOS once and logs the result; tool errors are returned cleanly when MemOS is unreachable rather than crashing the server.
How it integrates with Paperclip
The default config writes to MemOS scope user_id = kb-{companyId} — the same scope the Paperclip agent-memory plugin uses for its KB entries. This is the scope the OpenRouter adapter's pre-run hook queries when it builds the "## RELEVANT CONTEXT FROM PREVIOUS RUNS" block injected into every agent run.
So a memory you write from VS Code is, with zero plugin changes, automatically available to every Paperclip agent's next run. Bidirectional human ↔ agent memory.
If you don't want this — e.g. you want personal notes that Paperclip agents can't see — change MEMOS_USER_ID in the env block to something like seth-personal.
Install (macOS)
git clone https://github.com/mchosc/memos-mcp-server.git ~/Documents/GitHub/animusystems/memos-mcp-server
cd ~/Documents/GitHub/animusystems/memos-mcp-server
bash install.shThen open ~/Library/Application Support/Code/User/mcp.json and add the entry from vscode-mcp.snippet.json under the servers object. Reload VS Code (Cmd+Shift+P → "Developer: Reload Window").
The server will auto-start the next time you open the Chat panel and use any MCP tool. Verify it's connected by asking: "What MCP tools do you have?"
Configuration
All config is read from environment variables, which you set in the VS Code mcp.json env block:
Env var | Default | Purpose |
|
| MemOS HTTP base URL |
| Animus Group UUID | Paperclip companyId — used as MemOS cube |
|
| MemOS user_id scope (default: shared with agent KB) |
|
| Author tag stamped on every entry |
|
| Origin tag (e.g. |
|
| HTTP request timeout |
A note on MemOS consolidation
MemOS stores raw entries via /product/add but its internal pipeline runs an LLM (Mistral Small 3.2 in the Animus deployment) to consolidate raw entries into "evolving knowledge objects" — paraphrased, deduplicated versions of related memories. Searches return both the raw entries and the consolidated ones, and the consolidated ones often outrank the raw because they're cleaner.
Practical implication: the inline [source: human] / [author: seth] / [category: note] tags this MCP server adds to your content may not survive consolidation. The semantic content is preserved (your decisions, conventions, and notes still appear in search results), but the structured metadata block can be paraphrased away.
When that happens, search results display (consolidated) instead of the raw tag values. The only_human=True filter in memos_search only works for entries that still carry the raw tags — useful when you've just stored something, less useful weeks later when consolidation has run.
If you want guaranteed verbatim recall of personal notes, set MEMOS_USER_ID to a separate scope (e.g. seth-personal-raw) and skip the shared KB scope. That trade-off costs you the bidirectional human↔agent visibility.
Sanitizer
memos_remember runs the content through a regex sanitizer (sanitizer.py) before storing. Patterns currently covered:
Credit card numbers (Visa / MC / Amex / Discover)
IBAN
US SSN
PEM private keys
AWS access keys / secret keys
Generic API keys (
sk-,sk-or-v1-,sk-ant-, GitHub PATsghp_*/gho_*, GitLabglpat-, Slackxox[bps]-)Bearer tokens
Connection strings with embedded creds (postgres / mysql / mongodb / redis / amqp / smtp)
JWT tokens
Password / token assignments (
password=...,api_key: ..., etc.)
These are ported from paperclip-plugin-agent-memory/src/worker/sanitizer.ts. If new patterns get added there, port them here too — the README documents what's covered.
When something is redacted, the tool's response includes a note like "sanitized: 1x api_key" so you know it happened.
Usage examples
From any MCP client connected to this server, just ask:
"Remember that we set autoDecompose to false on the Animus Group task-triage plugin to stop routine fires from being decomposed into stuck-blocked subtasks."
The model calls memos_remember(content="...", category="decision", project="paperclip", tags=["task-triage", "routines"]). Done.
A week later from a fresh session:
"Why did we disable autoDecompose on task-triage?"
The model calls memos_search(query="autoDecompose task-triage") and gets the original decision back, verbatim, with the date and reason.
Troubleshooting
MemOS unreachable at http://localhost:8000
Docker stack isn't running. cd ~/Documents/paperclip-data && ./restart.sh or docker compose up -d memos.
Tools don't appear in VS Code chat
Check the mcp.json was saved with valid JSON (
jq < ~/Library/Application\ Support/Code/User/mcp.json)Reload VS Code (
Cmd+Shift+P → "Developer: Reload Window")Open the Chat panel → MCP servers panel; you should see
memoslistedIf it shows as failed, run the server manually to see the error:
/Users/seth/Documents/GitHub/animusystems/memos-mcp-server/.venv/bin/python3 /Users/seth/Documents/GitHub/animusystems/memos-mcp-server/server.py(it will block on stdin — that's fine, you just want to see startup logs on stderr)
Memories aren't showing up in agent runs
The shared kb-{companyId} scope is only auto-injected by the Paperclip agent-memory plugin's pre-run hook. Check:
The plugin is loaded:
docker logs paperclip-data-server-1 2>&1 | grep agent-memoryYour memory has the right
cube_id(matches the agent's companyId)The relevance ranking — MemOS is semantic, so unrelated queries won't surface your note. Try a
memos_searchwith a similar query first to confirm it's findable.
I want personal notes that agents can't see
Change MEMOS_USER_ID in your mcp.json env block from kb-... to something like seth-personal. The server will use that scope instead, and agent runs (which still query kb-...) won't see those entries.
License
MIT
Available Tools
3 toolsmemos_recentA
List recent memories from the last N hours.
Useful for "what was I working on yesterday?". Searches with a wildcard query then sorts client-side by stored_at timestamp.
Args: hours: How many hours back to look (default 24). source: Optional filter on the [source: ...] tag, e.g. "human".
| Name | Required | Description | Default |
|---|---|---|---|
| hours | No | ||
| source | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals internal behavior: 'Searches with a wildcard query then sorts client-side by stored_at timestamp.' With no annotations provided, this is valuable transparency about how the tool works.
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 a few sentences long, front-loaded with the purpose, and uses a clean Args section for parameters. Every sentence adds value 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?
For a simple tool with two optional parameters and an existing output schema, the description covers the purpose, behavior, parameters, and a use case. No additional information seems necessary.
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 0%, but the description fully explains both parameters: 'hours' (with default and meaning) and 'source' (with example). This adds critical meaning beyond the schema's type/default info.
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 'List recent memories from the last N hours' with a specific verb and resource, and provides an example use case. It is immediately distinct from sibling tools 'memos_remember' and 'memos_search'.
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?
It gives a concrete usage scenario ('what was I working on yesterday?'), which helps the agent understand when to invoke it. However, it does not explicitly contrast with sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memos_rememberA
Store a memory in MemOS, visible to both human and Paperclip agent searches.
The content is sanitized (credentials, API keys, tokens, JWTs etc. are redacted) before being stored. Use this to capture decisions, conventions, debugging insights, or anything you want to recall later — or want your Paperclip agents to know about on their next run.
Args: content: The text to remember. Will be auto-sanitized for credentials. category: One of decision, learning, fact, preference, note, convention. project: Optional project tag, e.g. "paperclip", "accounts", "memos". tags: Optional free-form tag list.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| category | No | note | |
| project | No | ||
| tags | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavior: content is sanitized (credentials redacted) and stored for future recall. However, it omits details like success/failure responses or idempotency.
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 well-structured with a summary line, behavioral note, and parameter list. It is appropriately sized and front-loaded, though a slight reduction in the use-case enumeration could improve conciseness.
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 complexity (write operation with sanitization) and presence of an output schema, the description covers essential aspects but could benefit from mentioning what happens on success or failure.
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?
Despite 0% schema description coverage, the 'Args' section explains each parameter's purpose, including auto-sanitization for content and valid categories (decision, learning, etc.), adding significant meaning beyond the schema.
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 'Store a memory in MemOS' and lists specific use cases (decisions, conventions, debugging insights). It implicitly distinguishes from siblings by focusing on writing, while memos_recent and memos_search are retrieval tools.
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 provides clear context on when to use (capture decisions, conventions, etc.) but does not explicitly mention when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memos_searchA
Search MemOS for memories matching a query.
Returns the top matches as a markdown list with score, source, category, project, and content excerpt. Searches the same scope that Paperclip agents read from, so results include both human notes and any agent KB entries (completed issues, executive briefs, indexed documents).
Args: query: Natural language query, e.g. "rename routine convention". top_k: Maximum number of results to return (default 5, max 25). only_human: If True, filter results to entries with [source: human]. Use this when you specifically want notes Seth wrote, not agent runs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No | ||
| only_human | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the scope (same as Paperclip agents) and that results are a markdown list, but does not explicitly state read-only behavior or any side effects.
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 well-structured with a clear first sentence, a paragraph explaining return format and scope, and an argument list. Every part adds value without 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 there is an output schema, the description appropriately does not detail return values. It covers parameter semantics and scope well, but lacks mention of idempotency or auth requirements, though these are less critical for a search tool.
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?
With 0% schema coverage, the description adds detailed meaning for all three parameters: 'query' (natural language), 'top_k' (default 5, max 25), and 'only_human' (filter to human notes), significantly enhancing understanding.
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 searches memories by query, and distinguishes it from siblings 'memos_recent' and 'memos_remember' by specifying it returns top matches.
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 implies usage context (search vs. recent vs. remember) but does not explicitly state when to use alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool serves a clear, distinct purpose: storing memories, retrieving recent ones, and searching by query. No overlap exists between the three operations.
All tools follow a consistent 'memos_<verb>' pattern (remember, recent, search), making the naming predictable and easy to understand.
With 3 tools, the count is slightly on the low side but appropriate for a focused memory server. It covers the core operations without unnecessary bloat.
The tool set lacks update and delete operations, which are notable gaps for a complete memory management system. However, the retrieval and creation tools are well-implemented.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
Read and write your Fresh Jots notes from Claude, Cursor, and any MCP client.
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
Google Keep-style notes app with an MCP server for AI agents to read/write notes.
Related MCP Servers
- AlicenseCqualityDmaintenanceMCP server for sharing source-backed engineering memory across AI coding clients like Cursor and VS Code.301MIT
- AlicenseNot gradedqualityCmaintenanceMCP server for AI agents to read, write, and organize notes in a local-first, human-in-the-loop note-taking app.62MIT
- AlicenseNot gradedqualityBmaintenanceLocal persistent memory for AI coding tools. Stores project context and conversation recall locally via MCP.1114MIT
- AlicenseNot gradedqualityAmaintenanceA universal MCP server providing persistent, structured memory through a knowledge graph with graph storage, semantic vector search, and multi-hop traversal for AI agents and IDEs.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mchosc/memos-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server