The MCP Server Memos allows interaction with a Memos server for memo management through the MCP protocol. You can:
Search memos: Find memos using keywords
Create memos: Add new memos with customizable visibility (PUBLIC, PROTECTED, or PRIVATE)
Retrieve memos: Fetch a specific memo by its ID
List tags: View all existing memo tags with filtering options by visibility and parent
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., "@MCP Server Memos search for memos about meeting notes"
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.
A Python package that provides LLM models with the ability to interact with Memos server through the MCP (Model Context Protocol) interface.
🔍 Search memos with keywords
✨ Create new memos with customizable visibility
📖 Retrieve memo content by ID
🏷️ List and manage memo tags
🔐 Secure authentication using access tokens
Related MCP server: MemOS-MCP
You can include this package in your config file as bellow, just as you use other Python MCP plugins.
{
...,
"mcpServers": {
"fetch": { // other mcp servers
"command": "uvx",
"args": ["mcp-server-fetch"]
},
"memos": { // add this to your config
"command": "uvx",
"args": [
"--prerelease=allow",
"mcp-server-memos",
"--host",
"localhost",
"--port",
"5230",
"--token",
"your-access-token-here"
]
}
}
}To install mcp-server-memos-py for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @RyoJerryYu/mcp-server-memos-py --client claudepip install mcp-server-memosmcp-server-memos --host localhost --port 8080 --token YOUR_ACCESS_TOKENfrom mcp_server_memos import Config, serve_stdio
config = Config(
host="localhost",
port=8080,
token="YOUR_ACCESS_TOKEN"
)
await serve_stdio(config=config)Parameter | Description | Default |
| Memos server hostname |
|
| Memos server port |
|
| Access token for authentication |
|
This MCP server provides the following tools for interacting with Memos:
Tool Name | Description | Parameters |
| List all existing memo tags | - |
| Search for memos using keywords | - |
| Create a new memo | - |
| Get a specific memo by ID | - |
Contributions are welcome! Please feel free to submit a Pull Request.
This project is licensed under the MIT License - see the LICENSE file for details.
Memos - A lightweight, self-hosted memo hub
MCP (Model Context Protocol) - Protocol for LLM model applications
Create a new memo
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The content of the memo. | |
| visibility | No | The visibility of the memo. | PRIVATE |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency. It only says 'Create a new memo', omitting side effects, permissions, idempotency, or any other behavioral traits. This is insufficient.
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 very concise (one sentence), but it is under-specified. Conciseness is not automatically high; it should balance brevity with informativeness. Here, it is acceptable but not exceptional.
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?
The description lacks details about return values, side effects, or post-creation behavior. Given no output schema, the description should compensate, but it does not. Incomplete for a creation 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?
Input schema coverage is 100% with descriptions for both parameters (content and visibility). The tool description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
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 'Create a new memo' clearly states the action (create) and resource (memo), making the purpose obvious. However, it does not differentiate from siblings like get_memo or search_memo, but those are distinct operations, so clarity is high.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it, which is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a memo
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the memo. Format: memos/{id} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only states 'Get' which implies a read, but it does not mention idempotency, side effects, authentication needs, or any constraints.
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 extremely concise at three words, but it sacrifices necessary detail. It fails to add value beyond the tool name, making it under-specified rather than efficiently concise.
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 and no annotations, the description should compensate by explaining what the memo contains or the return format. It does not, leaving the agent underinformed for a simple get 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?
The input schema already provides a clear description for the 'name' parameter (format: memos/{id}), so the description adds no new meaning. With 100% schema coverage, a baseline of 3 is appropriate.
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 'Get a memo' clearly states the action and resource, but it is too vague to distinguish from sibling tools like 'search_memo'. It lacks specificity about what kind of memo or scope.
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?
No usage guidance is provided. The description does not indicate when to use 'get_memo' versus alternatives like 'create_memo' or 'search_memo'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all existing memo tags
| Name | Required | Description | Default |
|---|---|---|---|
| parent | No | The parent, who owns the tags. Format: memos/{id}. Use "memos/-" to list all tags. | memos/- |
| visibility | No | The visibility of the tags. | PRIVATE |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose read-only nature, rate limits, or whether listing all tags includes inherited visibility. The tool is likely safe but unstated.
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?
Efficient single sentence, front-loaded with purpose, no unnecessary words.
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?
No output schema and description does not clarify return structure, but the tool is simple and siblings do not provide tags, so minimal completeness suffices.
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 descriptions for both parameters; description adds no additional meaning beyond 'list all tags'.
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 clearly states verb 'list' and resource 'memo tags', but omits that filtering is available via parameters, making it slightly incomplete.
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?
No guidance on when to use this tool versus siblings like get_memo or search_memo, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for memos
| Name | Required | Description | Default |
|---|---|---|---|
| key_word | Yes | The key words to search for in the memo content. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as search scope, result limits, pagination, or case sensitivity. For a search tool, this is a critical gap.
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 single sentence, which is concise, but it lacks necessary detail. It is not overly long, but could be more informative without being verbose.
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 should hint at return structure. It does not. The tool is simple, but the description is incomplete 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?
Schema description coverage is 100% with 'key_word' clearly described as 'The key words to search for in the memo content.' The description adds no additional meaning beyond the schema, earning a 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?
The description 'Search for memos' states the verb and resource, but it is vague and does not explicitly distinguish from siblings like get_memo. The schema clarifies it searches by keyword in content, so purpose is somewhat clear.
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?
No guidance on when to use this tool versus alternatives (e.g., get_memo for exact ID search, list_memo_tags for tags). The description lacks context for appropriate usage.
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. Dates show when Glama detected each change.
create_memoget_memolist_memo_tagssearch_memoEach tool has a clearly distinct purpose: creating, retrieving, searching memos, and listing tags. No overlap in functionality.
All tool names follow a consistent verb_noun pattern (create_memo, get_memo, list_memo_tags, search_memo), making them predictable.
Four tools is an appropriate count for a memo server, covering core operations without being excessive or insufficient.
Missing update and delete operations for memos, which are essential for full lifecycle management. The tool set covers only create, read, search, and tag listing.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Securely search, create, and organize your Mem notes and collections from AI assistants.
Universal memory for AI agents and tools. Save, organize and search context anywhere.
Connect AI to your flomo notes. Search, create, edit notes and manage tags via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RyoJerryYu/mcp-server-memos-py'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
