MCP(Model Context Protocol) 인터페이스를 통해 LLM 모델이 Memos 서버와 상호 작용할 수 있는 기능을 제공하는 Python 패키지입니다.
🔍 키워드로 메모 검색
✨ 사용자 정의 가능한 가시성으로 새 메모를 만드세요
📖 ID로 메모 내용 검색
🏷️ 메모 태그를 나열하고 관리하세요
🔐 액세스 토큰을 사용한 보안 인증
Related MCP server: MemOS-MCP
다른 Python MCP 플러그인을 사용하는 것과 마찬가지로, 아래와 같이 이 패키지를 설정 파일에 포함할 수 있습니다.
지엑스피1
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 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
메모 - 가볍고 자체 호스팅되는 메모 허브
MCP(Model Context Protocol) - 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
