Memory Bank 是一个 MCP 服务器，可帮助团队创建、管理和访问结构化的项目文档。它生成并维护一组相互关联的 Markdown 文档，这些文档涵盖项目知识的各个方面，从总体目标到技术细节，再到日常进度。
AI 生成的文档：利用 Gemini API 自动生成全面的项目文档
结构化知识系统：以分层结构维护六种核心文档类型
MCP 集成：实现模型上下文协议，实现与 AI 助手的无缝集成
可定制的位置：指定您想要创建记忆库目录的位置
文档模板：项目简介、产品背景、系统模式等的预定义模板。
人工智能辅助更新：手动更新文档或在人工智能的帮助下重新生成文档
高级查询：使用上下文感知相关性排名搜索所有文档
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 start要将 Memory Bank 与模型上下文协议 (MCP) 集成，请将以下配置添加到mcp.json文件：
{
"memoryBank": {
"command": "node",
"args": ["/path/to/memory-bank-mcp/dist/index.js"],
"env": {
"GEMINI_API_KEY": "your_gemini_api_key_here"
}
}
}将/path/to/memory-bank-mcp/dist/index.js替换为您构建的 index.js 文件的绝对路径，并添加您的 Gemini API 密钥（如果适用）。
例子：
{
"memoryBank": {
"command": "node",
"args": ["/Users/username/memory-bank-mcp/dist/index.js"],
"env": {
"GEMINI_API_KEY": "AIzaSyXXXXXXXXXXXXXXXXXXXXXXXX"
}
}
}记忆库 MCP 通过模型上下文协议提供以下工具：
initialize_memory_bank创建包含所有文档模板的新存储库结构。
参数：
goal （字符串）：项目目标描述（至少 10 个字符）
geminiApiKey （字符串，可选）：用于文档生成的 Gemini API 密钥
location （字符串，可选）：将创建存储库文件夹的绝对路径
例子：
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_document更新存储库中的特定文档。
参数：
documentType （枚举）：以下之一： projectbrief 、 productContext 、 systemPatterns 、 techContext 、 activeContext 、 progress
content （字符串，可选）：文档的新内容
regenerate （布尔值，默认值：false）：是否使用 AI 重新生成文档
例子：
await callTool({
name: "update_document",
arguments: {
documentType: "projectbrief",
content: "# Project Brief\n\n## Purpose\nTo develop an advanced and user-friendly AI..."
}
});query_memory_bank使用上下文感知相关性排名搜索所有文档。
参数：
query （字符串）：搜索查询（至少 5 个字符）
例子：
await callTool({
name: "query_memory_bank",
arguments: {
query: "system architecture components"
}
});export_memory_bank导出所有存储库文档。
参数：
format （枚举，默认值：“folder”）：导出格式，可以是“json”或“folder”
outputPath （字符串，可选）：导出的自定义输出路径
例子：
await callTool({
name: "export_memory_bank",
arguments: {
format: "json",
outputPath: "/Users/username/Documents/exports"
}
});记忆库将项目知识组织成六种核心文档类型：
项目简介（ projectbrief.md ）：定义项目目标、范围和愿景的核心文件
产品上下文（ productContext.md ）：从用户角度记录产品功能
系统模式（ systemPatterns.md ）：建立系统架构和组件关系
技术背景（ techContext.md ）：指定技术堆栈和实现细节
活动上下文（ activeContext.md ）：跟踪当前任务、未解决的问题和开发重点
进度（ progress.md ）：记录已完成的工作、里程碑和项目历史
麻省理工学院
| 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.
