Memory Bankは、チームが構造化されたプロジェクトドキュメントを作成、管理、そしてアクセスするのに役立つMCPサーバーです。プロジェクトの大まかな目標から技術的な詳細、日々の進捗状況まで、プロジェクトの知識のさまざまな側面を捉えた、相互に連携したMarkdownドキュメントのセットを生成・管理します。
AI生成ドキュメント: Gemini APIを活用して包括的なプロジェクトドキュメントを自動的に生成します
構造化知識システム: 6つのコア文書タイプを階層構造で維持します
MCP統合: AIアシスタントとのシームレスな統合を実現するモデルコンテキストプロトコルを実装
カスタマイズ可能な場所: メモリバンクディレクトリを作成する場所を指定します
ドキュメント テンプレート: プロジェクト概要、製品コンテキスト、システム パターンなどの事前定義されたテンプレート。
AI支援による更新: ドキュメントを手動で更新するか、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 startMemory Bank を Model Context Protocol (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 (boolean, default: 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"
}
});メモリ バンクは、プロジェクトの知識を 6 つのコア ドキュメント タイプに整理します。
プロジェクト概要（ 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.
