Memory Bank es un servidor MCP que ayuda a los equipos a crear, gestionar y acceder a la documentación estructurada del proyecto. Genera y mantiene un conjunto de documentos Markdown interconectados que capturan diferentes aspectos del conocimiento del proyecto, desde los objetivos generales hasta los detalles técnicos y el progreso diario.
Documentación generada por IA : aprovecha la API de Gemini para generar automáticamente documentación completa del proyecto.
Sistema de conocimiento estructurado : mantiene seis tipos de documentos principales en una estructura jerárquica
Integración MCP : implementa el protocolo de contexto de modelo para una integración perfecta con asistentes de IA
Ubicación personalizable : especifique dónde desea que se cree su directorio del banco de memoria
Plantillas de documentos : Plantillas predefinidas para descripción del proyecto, contexto del producto, patrones del sistema, etc.
Actualizaciones asistidas por IA : actualice documentos manualmente o regenerelos con asistencia de IA
Consultas avanzadas : busque en todos los documentos con clasificación de relevancia según el contexto
Related MCP server: Gigaspec
# Clone the repository
git clone https://github.com/tuncer-byte/memory-bank-mcp.git
cd memory-bank-mcp
# Install dependencies
npm install
# Create .env file with your Gemini API key (optional)
echo "GEMINI_API_KEY=your_api_key_here" > .env# Start in development mode
npm run dev# Build the project
npm run build
# Start in production mode
npm run startPara integrar Memory Bank con el Protocolo de contexto de modelo (MCP), agregue la siguiente configuración a su archivo mcp.json :
{
"memoryBank": {
"command": "node",
"args": ["/path/to/memory-bank-mcp/dist/index.js"],
"env": {
"GEMINI_API_KEY": "your_gemini_api_key_here"
}
}
}Reemplace /path/to/memory-bank-mcp/dist/index.js con la ruta absoluta a su archivo index.js creado y agregue su clave API de Gemini (si corresponde).
Ejemplo:
{
"memoryBank": {
"command": "node",
"args": ["/Users/username/memory-bank-mcp/dist/index.js"],
"env": {
"GEMINI_API_KEY": "AIzaSyXXXXXXXXXXXXXXXXXXXXXXXX"
}
}
}El banco de memoria MCP proporciona las siguientes herramientas a través del Protocolo de contexto de modelo:
initialize_memory_bankCrea una nueva estructura de banco de memoria con todas las plantillas de documentos.
Parámetros:
goal (cadena): Descripción del objetivo del proyecto (mínimo 10 caracteres)
geminiApiKey (cadena, opcional): clave API de Gemini para la generación de documentos
location (cadena, opcional): ruta absoluta donde se creará la carpeta del banco de memoria
Ejemplo:
await callTool({
name: "initialize_memory_bank",
arguments: {
goal: "Building a self-documenting AI-powered software development assistant",
location: "/Users/username/Documents/projects/ai-assistant"
}
});update_documentActualiza un documento específico en el Banco de Memoria.
Parámetros:
documentType (enum): Uno de los siguientes: projectbrief , productContext , systemPatterns , techContext , activeContext , progress
content (cadena, opcional): Nuevo contenido para el documento
regenerate (booleano, valor predeterminado: falso): si se debe regenerar el documento utilizando IA
Ejemplo:
await callTool({
name: "update_document",
arguments: {
documentType: "projectbrief",
content: "# Project Brief\n\n## Purpose\nTo develop an advanced and user-friendly AI..."
}
});query_memory_bankBusca en todos los documentos con clasificación de relevancia según el contexto.
Parámetros:
query (cadena): consulta de búsqueda (mínimo 5 caracteres)
Ejemplo:
await callTool({
name: "query_memory_bank",
arguments: {
query: "system architecture components"
}
});export_memory_bankExporta todos los documentos del Banco de Memoria.
Parámetros:
format (enumeración, predeterminado: "carpeta"): formato de exportación, ya sea "json" o "carpeta"
outputPath (cadena, opcional): ruta de salida personalizada para la exportación
Ejemplo:
await callTool({
name: "export_memory_bank",
arguments: {
format: "json",
outputPath: "/Users/username/Documents/exports"
}
});Memory Bank organiza el conocimiento del proyecto en seis tipos de documentos principales:
Resumen del proyecto ( projectbrief.md ): documento central que define los objetivos, el alcance y la visión del proyecto.
Contexto del producto ( productContext.md ): documenta la funcionalidad del producto desde la perspectiva del usuario
Patrones del sistema ( systemPatterns.md ): Establece la arquitectura del sistema y las relaciones entre los componentes.
Contexto tecnológico ( techContext.md ): especifica la pila de tecnología y los detalles de implementación
Contexto activo ( activeContext.md ): realiza un seguimiento de las tareas actuales, los problemas abiertos y el enfoque de desarrollo
Progreso ( progress.md ): Documenta el trabajo completado, los hitos y el historial del proyecto.
Instituto Tecnológico de Massachusetts (MIT)
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Absolute path where cursor-rules will be created | |
| projectPurpose | Yes | Proje amacını detaylı bir şekilde açıklayan bir metin giriniz. Bu metin projenin temel hedeflerini ve kapsamını belirleyecektir. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Export format | folder |
| outputPath | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| geminiApiKey | No | Gemini API key (optional) | |
| goal | Yes | ||
| location | Yes | Absolute path where memory-bank folder will be created |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | ||
| documentType | Yes | ||
| regenerate | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.
v1.0.0create_cursor_rulesexport_memory_bankinitialize_memory_bankquery_memory_bankupdate_documentScored across 5 tools
The tools have distinct purposes based on their names: creating rules, exporting, initializing, querying, and updating documents. However, without descriptions, there is some ambiguity about the exact boundaries between 'create_cursor_rules' and 'update_document', or whether 'initialize_memory_bank' overlaps with other setup tasks. Overall, they appear mostly distinct but could benefit from clearer differentiation.
All tool names follow a consistent verb_noun pattern with snake_case, such as 'create_cursor_rules', 'export_memory_bank', and 'query_memory_bank'. There are no deviations in naming style or convention, making the set predictable and easy to parse for an agent.
With 5 tools, the count is well-scoped for a memory bank server, covering core operations like initialization, querying, updating, exporting, and rule creation. Each tool seems to earn its place without being overly sparse or bloated, fitting typical expectations for such a domain.
The tools cover key aspects like initialization, querying, updating, and exporting, but there are notable gaps. For example, there is no tool for deleting documents or rules, and operations like listing or searching memory contents are missing. This could lead to agent workarounds or failures in full lifecycle management.
MCP server for generating rough-draft project plans from natural-language prompts.
Hosted markdown project wikis your team's AI assistants read, search, and update over MCP.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Team docs served to AI agents over MCP - search, Markdown reads, version pinning, read audit.
