Un paquete de Python que proporciona a los modelos LLM la capacidad de interactuar con el servidor Memos a través de la interfaz MCP (Protocolo de contexto de modelo) .
🔍Buscar notas con palabras clave
✨ Crea nuevas notas con visibilidad personalizable
📖 Recuperar contenido de notas por ID
🏷️ Enumerar y administrar etiquetas de notas
🔐 Autenticación segura mediante tokens de acceso
Related MCP server: MemOS-MCP
Puede incluir este paquete en su archivo de configuración como se muestra a continuación, tal como usa otros complementos MCP de Python.
{
...,
"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"
]
}
}
}Para instalar mcp-server-memos-py para Claude Desktop automáticamente a través de 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)Parámetro | Descripción | Por defecto |
| Nombre de host del servidor Memos |
|
| Puerto del servidor de notas |
|
| Token de acceso para autenticación |
|
Este servidor MCP proporciona las siguientes herramientas para interactuar con Memos:
Nombre de la herramienta | Descripción | Parámetros |
| Listar todas las etiquetas de notas existentes | - |
| Buscar notas usando palabras clave | - |
| Crear una nueva nota | - |
| Obtenga una nota específica por identificación | - |
¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.
Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.
Memos : un centro de notas ligero y autoalojado
MCP (Protocolo de Contexto de Modelo) : Protocolo para aplicaciones del modelo 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
