LLM モデルにMCP (モデル コンテキスト プロトコル)インターフェイスを介してMemosサーバーと対話する機能を提供する Python パッケージ。
🔍 キーワードでメモを検索する
✨ 表示設定をカスタマイズして新しいメモを作成
📖 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)パラメータ | 説明 | デフォルト |
| メモサーバのホスト名 |
|
| メモサーバーポート |
|
| 認証用のアクセストークン |
|
この MCP サーバーは、メモと対話するための次のツールを提供します。
ツール名 | 説明 | パラメータ |
| 既存のメモタグをすべて一覧表示する | - |
| キーワードを使ってメモを検索する | - |
| 新しいメモを作成する | - |
| IDで特定のメモを取得する | - |
貢献を歓迎します！お気軽にプルリクエストを送信してください。
このプロジェクトは 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
