一个 Python 包，为 LLM 模型提供通过MCP（模型上下文协议）接口与Memos服务器交互的能力。
🔍 使用关键字搜索备忘录
✨ 创建具有可自定义可见性的新备忘录
📖 通过 ID 检索备忘录内容
🏷️ 列出和管理备忘录标签
🔐 使用访问令牌进行安全身份验证
Related MCP server: MemOS-MCP
您可以将此包包含在您的配置文件中，就像使用其他 Python MCP 插件一样。
{
...,
"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"
]
}
}
}要通过Smithery自动为 Claude Desktop 安装 mcp-server-memos-py：
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)范围 | 描述 | 默认 |
| Memos 服务器主机名 |
|
| 备忘录服务器端口 |
|
| 用于身份验证的访问令牌 |
|
该 MCP 服务器提供以下与 Memos 交互的工具：
工具名称 | 描述 | 参数 |
| 列出所有现有的备忘录标签 | - |
| 使用关键字搜索备忘录 | - |
| 创建新备忘录 | - |
| 通过 ID 获取特定备忘录 | - |
欢迎贡献代码！欢迎提交 Pull 请求。
该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅LICENSE文件。
Memos - 轻量级、自托管的备忘录中心
MCP（模型上下文协议） ——LLM 模型应用协议
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
