What can you do with this server?

The mcp-zip server provides a compressed memory system for AI agents, enabling efficient storage, search, and retrieval of contextual information across sessions while minimizing token usage. * Initialize Projects (memoria_iniciar): Create or reactivate memory projects with an optional tech stack description; auto-archives entries older than 30 days. * Write Memory Entries (memoria_escribir): Record structured entries (bugs, decisions, implementations, plans) with fields like title, context, root cause, solution, tags, and affected files in compact Markdown format. * Search Memory (memoria_buscar): Full-text semantic search using FTS5 + TF-IDF across a project's entries (~700 tokens per search), with optional filtering for active entries only. * Read Memory Files (memoria_leer): Read complete memory files (e.g., resumen, errores, decisiones, implementacion, plan) for a given project. * Generate Summaries (memoria_resumen): Get a compact project status summary (~500 tokens). * List Projects (memoria_listar): View all existing memory projects. * Archive Old Entries (memoria_archivar): Automatically move resolved entries older than a configurable threshold (default: 30 days) into an archive vault. * Import Existing Markdown (memoria_importar): Migrate existing .md context files into the mcp-zip system. * Export Memory (memoria_exportar): Export the content of a specific memory file from a project. * Synchronize Data (memoria_sincronizar): Rebuild and sync the JSON cache and SQLite index across all projects. * Statistics (memoria_estadisticas): View token savings and memory usage metrics. * Zip Export/Import: Package and unpackage entire projects into/from .mcp-zip compressed archives, and inspect archive contents.

How do I use mcp-zip?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-zip search for 'color detection' in ferreteria" 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.

mcp-zip

by nanodaniel69

Overview Schema Related Servers Score Discussions

Python

Local

mcp-zip 🗜️

Memoria comprimida para agentes de IA.

Python 3.10+ License: MIT MCP

mcp-zip es un servidor MCP que comprime el contexto de tu agente de IA. En vez de leer archivos completos (miles de tokens), busca solo lo relevante (decenas de tokens). Como un ZIP, pero para la memoria del agente.

El Problema

Tu agente de IA olvida todo cada vez que termina una sesión. Para recordar, tiene que leer archivos completos de contexto — consumiendo miles de tokens en cada conversación. Al final del día, llegás al rate limit.

Related MCP server: context-vault

La Solución

mcp-zip comprime la memoria del agente en archivos .md compactos, optimizados para consumo de LLMs. Con búsqueda FTS5 + TF-IDF, tu agente encuentra lo relevante en milisegundos sin leer archivos completos.

Arquitectura

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  .md files   │────▶│  .json cache │────▶│  SQLite      │
│  (store)     │     │  (estructura)│     │  (índice)    │
│  git-friendly│     │  parseo rápido│    │  FTS5+TF-IDF │
└──────────────┘     └──────────────┘     └──────────────┘
       │                    │                    │
       ▼                    ▼                    ▼
  Humanos leen       APIs acceden        Agente busca
  y commitean        programátic.        instantáneo

Flujo de Trabajo

INICIAR SESIÓN:
  memoria_iniciar("ferreteria")
  → Auto-archiva entradas >30 días
  → ✅ Proyecto activo

ESCRIBIR:
  memoria_escribir("ferreteria", "bug", "Color falla", ...)
  → Guarda en .md (git)
  → Genera .json (cache)
  → Indexa en SQLite (búsqueda)

BUSCAR:
  memoria_buscar("ferreteria", "color detection")
  → SQLite FTS5 + TF-IDF busca (~700 tokens)
  → Devuelve solo entradas relevantes

LEER:
  memoria_leer("ferreteria", "resumen")
  → Lee .md completo (~500 tokens)
  → Solo para contexto general

Instalación

pip install mcp-zip

Configurar en tu Editor

Zed

Agrega en ~/.config/zed/settings.json:

{
  "context_servers": {
    "zip": {
      "command": "mcp-zip"
    }
  }
}

Claude Desktop

Agrega en claude_desktop_config.json:

{
  "mcpServers": {
    "zip": {
      "command": "mcp-zip"
    }
  }
}

Cursor

Agrega en .cursor/mcp.json:

{
  "mcpServers": {
    "zip": {
      "command": "mcp-zip"
    }
  }
}

Cualquier Cliente MCP

{
  "mcpServers": {
    "zip": {
      "command": "mcp-zip",
      "env": {
        "MEMORIA_ROOT": "~/.memoria"
      }
    }
  }
}

Herramientas

Herramienta	Descripción	Tokens
`memoria_iniciar`	Crea/reactiva proyecto + auto-archiva	~50
`memoria_escribir`	Registra entrada (bug, decisión, plan)	~100
`memoria_buscar`	Búsqueda semántica FTS5 + TF-IDF	~700
`memoria_leer`	Lee archivo completo	~500-5000
`memoria_resumen`	Resumen compacto del estado	~500
`memoria_listar`	Lista todos los proyectos	~100
`memoria_archivar`	Archiva entradas >30 días en bóveda	~50
`memoria_importar`	Migra .md existentes al sistema	~200
`memoria_exportar`	Exporta archivo de memoria	variable
`memoria_estadisticas`	Métricas de uso y ahorro de tokens	~300
`memoria_sincronizar`	Sync JSON + SQLite de todos los proyectos	~500
`memoria_exportar_zip`	Exporta proyecto a formato .mcp-zip	~200
`memoria_importar_zip`	Importa proyecto desde .mcp-zip	~300
`memoria_listar_zip`	Lista contenido de un .mcp-zip	~100

Flujo Óptimo (Ahorra Tokens)

❌ Mal (consume ~50,000 tokens/sesión)

# Leer TODO el contexto cada vez
memoria_leer("ferreteria", "errores")      # 3,716 tokens
memoria_leer("ferreteria", "decisiones")    # 5,901 tokens
memoria_leer("ferreteria", "implementacion") # 2,862 tokens

✅ Bien (consume ~3,500 tokens/sesión)

# Resumen general
memoria_resumen("ferreteria")              # 500 tokens

# Búsqueda específica
memoria_buscar("ferreteria", "parser")     # 700 tokens
memoria_buscar("ferreteria", "color")      # 700 tokens

# Lectura solo si es necesario
memoria_leer("ferreteria", "resumen")      # 500 tokens

Ahorro: 93% de tokens por sesión.

Formato Compacto

mcp-zip usa un formato .md optimizado para modelos de IA:

### bug | 2026-07-14 | resuelto
Color detection no funciona
ctx: Pinturas Tekbond/Miura se fusionan
root: paso 8 parser FGP, result.attributes sobreescribe objeto
fix: result.attributes = { ...result.attributes, features }
tags: parser,fgp,colores
files: src/services/normalization/parsers/fgp.parser.ts

vs formato tradicional (2x más tokens):

## [2026-07-14] Bug: Color detection no funciona 🟢 Resuelto

- **Contexto**: Pinturas Tekbond/Miura se fusionan al no detectar color
- **Causa raíz**: En el paso 8 del parser FGP, `result.attributes = { features: ... }` SOBREESCRIBÍA el objeto
- **Solución**: Cambiar por `result.attributes = { ...result.attributes, features: ... }`
- **Estado**: 🟢 Resuelto

Bóveda de Archivado

Las entradas resueltas con más de 30 días se archivan automáticamente al iniciar sesión:

~/.memoria/proyectos/ferreteria/
├── errores.md          ← Entradas activas
├── errores.json        ← Cache estructurado
├── decisiones.md       ← Entradas activas
├── decisiones.json     ← Cache estructurado
├── memoria.db          ← Índice FTS5 + TF-IDF
└── boveda/
    ├── errores-2026-06.md      ← Archivados de junio
    ├── errores-2026-06.json    ← Cache de archivados
    ├── decisiones-2026-06.md
    └── decisiones-2026-06.json

Stores de Almacenamiento

Store	Formato	Para Qué	Quién lo Lee
`.md`	Markdown compacto	Git, humanos, backup	Cualquiera
`.json`	JSON estructurado	Acceso programático	Python, APIs
`.db`	SQLite FTS5 + TF-IDF	Búsqueda instantánea	Motor de búsqueda

Migración

Si ya tenés archivos .md de contexto existentes:

# El agente llama:
memoria_importar("ferreteria", "/home/user/proyectos/ferreteria/context/")
→ 📥 Importación completada: 5 archivos, 23 entradas
→ 📄 JSON sincronizado automáticamente

Variables de Entorno

Variable	Descripción	Default
`MEMORIA_ROOT`	Directorio raíz de almacenamiento	`~/.memoria`

Formato .mcp-zip

Formato comprimido para exportar/importar proyectos completos:

# Exportar proyecto
memoria_exportar_zip("ferreteria")
→ 📦 ferreteria.mcp-zip (24.5 KB → 8.2 KB comprimido)

# Importar proyecto
memoria_importar_zip("/backup/ferreteria.mcp-zip")
→ 📥 Proyecto 'ferreteria' importado (47 entradas)

# Listar contenido
memoria_listar_zip("ferreteria.mcp-zip")
→ 📋 Contenido:
   - errores.md (12 KB)
   - errores.json (8 KB)
   - decisiones.md (18 KB)
   - ...

Estadísticas

memoria_estadisticas("ferreteria")
→ 📊 Estadísticas:
   - Entradas: 47 (23 bugs, 15 decisiones, 9 planes)
   - Activas: 31 | Archivadas: 16
   - 💰 Ahorro: 93% (46,500 tokens/sesión)

Sincronización

memoria_sincronizar()
→ 🔄 Sincronizando todos los proyectos...
   - ferreteria: ✅ JSON + SQLite reconstruido
   - matucho: ✅ JSON + SQLite reconstruido

Stats del Proyecto

Líneas de código:  ~2,200
Tests:             35/35 ✅
Dependencias:      2 (fastmcp, pyyaml)
Formato:           .md + .json + SQLite
Búsqueda:          FTS5 + TF-IDF (sin ML)

Licencia

MIT — Ver LICENSE

mcp-zip — Comprime la memoria de tu agente. Ahorra tokens. Nunca olvide. 🗜️

Available Tools

9 tools

memoria_archivarA

Archiva entradas resueltas antiguas en la bóveda.

ParametersJSON Schema

Name	Required	Description	Default
`dias`	No	Días de antigüedad para archivar (default: 30)
`nombre`	Yes	Nombre del proyecto

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as whether archiving is destructive, reversible, or requires specific permissions. It uses the verb 'Archiva' without clarifying the underlying action (e.g., move, copy, delete).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but could benefit from additional structure, such as separating purpose from usage notes. It is clear but minimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no schema complexity), the description is partially complete. However, lacking annotations and explicit behavioral details, it falls short of fully informing an agent. The presence of an output schema (not detailed) does not compensate for the missing transparency.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning beyond the input schema by linking 'antiguas' (old) to the 'dias' parameter and 'resueltas' (resolved) to the action. Both parameters are fully documented in the schema (100% coverage), but the description provides context that clarifies how they relate to the tool's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Archiva'), the resource ('entradas resueltas antiguas'), and the destination ('en la bóveda'). It distinguishes itself from sibling tools like 'memoria_buscar' or 'memoria_escribir' by focusing on archiving old resolved entries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for archiving old resolved entries, but does not explicitly state when to use this tool versus alternatives. No when-not or alternative tool mentions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memoria_buscarC

Busca entradas de memoria por texto completo.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Texto a buscar
`nombre`	Yes	Nombre del proyecto
`solo_activos`	No	Si es True, solo busca en entradas no archivadas

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must convey behavior. It implies a read-only search but does not explicitly state non-destructiveness, performance characteristics, or what happens with no results. The return format is not described, though an output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the purpose. It is efficiently worded, but could benefit from slight expansion without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of sibling tools and no output schema details in the description, the definition lacks context on when to search vs read/list, and omits behavioral traits like pagination or filtering behavior. Incomplete for a 3-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are well documented in the input schema. The description adds no additional semantic context beyond the schema (e.g., how 'query' is matched, case sensitivity). Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches memory entries by full text (verb 'busca' + resource 'entradas de memoria' + method 'por texto completo'). It is distinct from sibling tools like 'memoria_leer' (read specific) and 'memoria_listar' (list all), but lacks nuance about scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 (e.g., 'memoria_leer' or 'memoria_listar'). No when-to-use, when-not-to-use, or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memoria_escribirC

Escribe una entrada de memoria en formato compacto.

ParametersJSON Schema

Name	Required	Description	Default
`tipo`	Yes	Tipo de entrada (bug, decision, implementacion, plan)
`estado`	No	Estado (activo, resuelto, pendiente)	activo
`nombre`	Yes	Nombre del proyecto
`titulo`	Yes	Título de la entrada
`impacto`	No	Impacto de la entrada
`archivos`	No	Archivos afectados (separados por coma)
`contexto`	No	Contexto del problema o decisión
`decision`	No	Decisión tomada (para decisiones)
`solucion`	No	Solución implementada
`etiquetas`	No	Etiquetas (separadas por coma)
`rationale`	No	Razonamiento de la decisión
`causa_raiz`	No	Causa raíz (para bugs)

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, and the description does not disclose behavioral traits such as side effects, permissions, or data format. The word 'compacto' hints at output format but is insufficient for understanding mutation behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise, but it is too sparse to be effective. It lacks structure and does not front-load important information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 12 parameters, an output schema exists but is not described, and the description is minimal. It fails to provide essential context about what 'compacto' means or the overall behavior of the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters with descriptions, so baseline is 3. The description does not add meaning beyond the schema; the 'compacto' reference is too vague to enhance parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the verb 'escribe' and object 'entrada de memoria', but it does not differentiate this tool from siblings like 'memoria_archivar' or 'memoria_leer'. The phrase 'formato compacto' adds some specificity but the purpose is generic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. The description lacks any context about prerequisites, typical scenarios, or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memoria_exportarC

Exporta un archivo de memoria (lee el contenido).

ParametersJSON Schema

Name	Required	Description	Default
`nombre`	Yes	Nombre del proyecto
`tipo_archivo`	No	Tipo de archivo a exportar	resumen

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description bears the full burden. It only states that the tool reads the content during export, but fails to disclose whether the export is destructive, what permissions are required, or the nature of the output. The existence of an output schema may partially compensate, but the description itself 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise but lacks structure. It front-loads the verb, but the parenthetical is unclear. Every word is used, but the overall clarity could be improved.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, return value explanation is not needed. However, the description fails to provide sufficient context about the export process, such as whether it creates a file, triggers a download, or modifies state. For a tool with two parameters and no annotations, more completeness is expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description does not add any information about the parameters beyond what is already in the schema (e.g., 'nombre' is project name, 'tipo_archivo' with default 'resumen'). No enhancement from the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'exportar' and the resource 'archivo de memoria', indicating an export action. However, it doesn't fully distinguish from sibling tools like 'memoria_archivar' or 'memoria_resumen', since 'exportar' could overlap with archiving or summary generation. The parenthetical 'lee el contenido' adds redundancy.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 vs alternatives such as 'memoria_leer' for reading or 'memoria_archivar' for archiving. There is no mention of prerequisites, context, or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memoria_importarB

Importa archivos .md desde una carpeta context/ existente.

ParametersJSON Schema

Name	Required	Description	Default
`ruta`	Yes	Ruta a la carpeta context/ (ej: /home/user/proyecto/context/)
`nombre`	Yes	Nombre del proyecto

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only states the import action, omitting side effects (e.g., overwrite behavior), error conditions, or whether it is destructive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, concise and front-loaded. However, it could include more detail without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the primary function but lacks details on where files are imported to (into memoria) and any constraints. An output schema exists but doesn't compensate for missing context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds no extra parameter details beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool imports .md files from an existing context/ folder, using a specific verb and resource. It distinguishes from siblings like export, write, and read.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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., when to import vs. write or read). No prerequisites or exclusions mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memoria_iniciarB

Crea un proyecto nuevo con la estructura de memoria.

ParametersJSON Schema

Name	Required	Description	Default
`stack`	No	Stack tecnológico opcional (ej: "Next.js + Prisma")
`nombre`	Yes	Nombre del proyecto (ej: "ferreteria")

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the full burden of behavioral disclosure. It only states it creates a project but does not mention side effects (e.g., overwriting existing projects), required permissions, or what 'estructura de memoria' entails, leaving significant behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently communicates the core purpose without any redundant wording. It is front-loaded and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 2 parameters and an output schema (not shown but present), the description is minimally complete. However, it lacks context about the project initialization process, such as idempotency or effects on existing data, which would be helpful for an agent operating this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the input schema already describes both parameters ('nombre' and 'stack'). The description adds no additional meaning beyond what the schema provides, achieving the baseline for parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Crea' (creates) and the resource 'un proyecto nuevo con la estructura de memoria'. It distinguishes itself from sibling tools like 'memoria_archivar' or 'memoria_buscar' by focusing on initialization of a new project, which is a distinct operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, nor any prerequisites or exclusions. The description is too minimal to inform an agent about context-specific usage decisions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memoria_leerC

Lee un archivo de memoria completo.

ParametersJSON Schema

Name	Required	Description	Default
`nombre`	Yes	Nombre del proyecto
`tipo_archivo`	No	Tipo de archivo a leer (resumen, errores, decisiones, implementacion, plan)	resumen

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only says 'reads a complete memory file' but does not mention side effects, permissions, rate limits, or return format (despite an output schema existing, the description adds no transparency).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise and front-loaded. However, it lacks essential details for a complete understanding, but still scores high for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (2 parameters, no nested objects, output schema exists), the description provides minimal context. It does not explain what 'completo' means or how the output is structured, but for a basic read operation it is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters have clear descriptions in the schema. The description does not add additional meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'lee' (reads) and the resource 'archivo de memoria' (memory file), so the basic purpose is clear. However, it does not differentiate from sibling tools like 'memoria_resumen' which might also read from memory, and 'completo' is ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidelines are provided. The description does not indicate when to use this tool over alternatives, nor does it give any prerequisites or contextual hints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memoria_listarA

Lista todos los proyectos con memoria.

Returns: Lista de proyectos con información básica

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It states it returns a list of projects with basic info, but does not specify if it is read-only, any authentication needs, or what 'información básica' includes. The return format is also left vague.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two short sentences. Every word is necessary and there is no fluff. It is front-loaded with the main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and the existence of an output schema (though not shown), the description is nearly complete. However, it lacks detail on the content of the returned list (e.g., which fields are included). Still, for a simple list-all tool, it is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and the schema coverage is 100%. Per guidelines, baseline is 4 with no parameters; the description does not need to add parameter info. It correctly implies no input needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Lista' (list) and the resource 'todos los proyectos con memoria', which distinguishes it from other tools like memoria_buscar (search) and memoria_leer (read specific).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 (e.g., memoria_buscar for filtered queries, memoria_leer for a specific project). There is no mention of when to use or not use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memoria_resumenC

Genera un resumen compacto del estado del proyecto.

ParametersJSON Schema

Name	Required	Description	Default
`nombre`	Yes	Nombre del proyecto

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the burden. It only states the action without disclosing side effects, permissions, or output characteristics. The agent cannot infer if it is read-only or requires special access.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, efficient and front-loaded. While minimal, it avoids wordiness, earning a high score for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (1 param, output schema exists, many siblings), the description is too brief. It lacks context on when to use and what the output contains, relying on external schema which the agent may not fully explore.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the parameter description in the schema is sufficient. The tool description adds no additional meaning beyond what is already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates a compact summary of project status, distinguishing it from siblings like read (memoria_leer) or list (memoria_listar). However, it is a single phrase without elaboration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. The description does not mention context, prerequisites, or exclusions, leaving the agent without decision support.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

9 tool updatesv0.1.0Jul 14, 2026
- First observedmemoria_archivar
- First observedmemoria_buscar
- First observedmemoria_escribir
- First observedmemoria_exportar
- First observedmemoria_importar
- First observedmemoria_iniciar
- First observedmemoria_leer
- First observedmemoria_listar
- First observedmemoria_resumen

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: archive, search, write, export, import, init, read, list, and summary. No two tools overlap in functionality.

Naming Consistency4/5

All tools follow the 'memoria_' prefix with a verb in Spanish, except 'resumen' which is a noun (summary). The pattern is mostly consistent but has a minor deviation.

Tool Count5/5

Nine tools is appropriate for a memory management system, covering core operations without being excessive or sparse.

Completeness4/5

The set covers create, read, search, list, archive, import, export, and init. Missing explicit update and delete operations, but archive may serve as soft delete, leaving a minor gap.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

NeuroStack
io.github.raphasouthall
Token-efficient MCP memory for Markdown vaults. Tiered search, GraphRAG, AI memories.
Knowledge & Memory RAG Systems Vector Databases
246
AI Context FlowOAuth
network.plurality
Universal memory for AI agents and tools. Save, organize and search context anywhere.
Knowledge & Memory Search
22
Memory VaultOAuth
io.github.apurv101
Portable AI memory shared across models and harnesses - plain markdown you own.
Knowledge & Memory File Systems
1
MemorySyncOAuth
io.memorysync
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
Knowledge & Memory Autonomous Agents
1

Related MCP Servers

Mneme Memory MCP
Knowledge & Memory File Systems
ethos-zero
A
license
A
quality
B
maintenance
A local-first shared memory layer for MCP-aware agents like Claude, Codex, and Hermes, enabling persistent memory across chats and clients via Markdown files and SQLite FTS.
Updated a month ago (2026-07-24 12:33 UTC)
6
2
MIT
context-vault
Knowledge & Memory Note Taking
fellanH
F
license
Not graded
quality
B
maintenance
Persistent memory for AI agents enabling saving, searching, and managing knowledge across sessions with local markdown files.
Updated 2 months ago (2026-07-10 09:23 UTC)
2
-
mcp-ai-brain
Knowledge & Memory AI & Machine Learning
nawkarpravinp-bit
A
license
Not graded
quality
D
maintenance
Persistent memory for AI coding agents with local-first, zero-cost, privacy-first SQLite/FTS5 storage and biological-inspired decay.
Updated 2 months ago (2026-07-15 02:32 UTC)
18
2
MIT
context-manager
Bhaskar-GameDev
A
license
Not graded
quality
C
maintenance
Local-first, cross-session context store that reduces token usage by saving facts, decisions, and preferences, and recalling them in later sessions with token-efficient ranking and compression.
Updated 2 months ago (2026-07-20 05:20 UTC)
7
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nanodaniel69/mcp-zip'

If you have feedback or need assistance with the MCP directory API, please join our Discord server