The Memory Bank MCP server is a structured documentation system for project knowledge management with the following capabilities:
Initialize Memory Bank: Create a new documentation structure with templates, project goals, and optional Gemini API key
AI-Generated Documentation: Automatically generate project documentation using the Gemini API
Structured Knowledge System: Maintain six core document types in a hierarchical structure
Update Documents: Modify or regenerate specific documents manually or with AI assistance
Query Memory Bank: Search across all documents with context-aware relevance ranking
Export Documentation: Export in JSON or folder format to a specified location
MCP Integration: Seamlessly integrate with AI assistants via the Model Context Protocol
Generates and maintains interconnected Markdown documents that capture different aspects of project knowledge in a structured format
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Memory Bank MCP initialize a memory bank for our new e-commerce platform project"
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.
Note: This is not a traditional Node.js application. Memory Bank MCP is an MCP server—a component in the Model Context Protocol ecosystem. It exposes project knowledge to LLM-powered agents and tools using a standardized protocol, enabling seamless integration with AI clients (e.g., Claude Desktop, IDEs, or custom LLM agents).
MCP is an open protocol that standardizes how applications provide context to LLMs. Think of MCP like a USB-C port for AI: it provides a universal way to connect AI models to data sources and tools, both locally and remotely. MCP enables:
Plug-and-play integrations between LLMs, data, and tools
Switching between LLM providers with minimal friction
Secure, modular architecture for building AI workflows
Learn more: MCP Introduction
Related MCP server: Gigaspec
Memory Bank MCP is an MCP server that helps teams create, manage, and access structured project documentation. It generates and maintains interconnected Markdown documents capturing all aspects of project knowledge, from high-level goals to technical details and daily progress. It is designed to be accessed by MCP-compatible clients and LLM agents.
AI-Generated Documentation: Uses Gemini API to generate and update project documentation
Structured Knowledge System: Maintains six core document types in a hierarchical structure
MCP Server: Implements the Model Context Protocol for integration with LLM agents and tools
Customizable Storage: Choose where your Memory Bank directory is created
Document Templates: Pre-defined templates for project brief, product context, system patterns, etc.
AI-Assisted Updates: Update documents manually or regenerate them with AI
Advanced Querying: Search across all documents with context-aware relevance ranking
# Clone the repository
git clone https://github.com/tuncer-byte/memory-bank-mcp.git
cd memory-bank-mcp
# Install dependencies
npm install
# (Optional) Create .env file with your Gemini API key
echo "GEMINI_API_KEY=your_api_key_here" > .envNote: Memory Bank MCP is intended to be run as an MCP server, not as a standalone app. You typically launch it as part of an MCP workflow, and connect to it from an MCP-compatible client (such as Claude Desktop or your own LLM agent).
npm run devnpm run build
npm run startTo connect Memory Bank MCP to your MCP client, add the following to your mcp.json configuration:
{
"memoryBank": {
"command": "node",
"args": ["/path/to/memory-bank-mcp/dist/index.js"],
"env": {
"GEMINI_API_KEY": "your_gemini_api_key_here"
}
}
}Replace /path/to/memory-bank-mcp/dist/index.js with the absolute path to your built file, and add your Gemini API key if needed.
Memory Bank MCP provides the following tools via the Model Context Protocol:
initialize_memory_bankCreates a new Memory Bank structure with all document templates.
Parameters:
goal (string): Project goal description (min 10 characters)
geminiApiKey (string, optional): Gemini API key for document generation
location (string, optional): Absolute path where memory-bank folder will be created
Example:
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_documentUpdates a specific document in the Memory Bank.
Parameters:
documentType (enum): One of: projectbrief, productContext, systemPatterns, techContext, activeContext, progress
content (string, optional): New content for the document
regenerate (boolean, default: false): Whether to regenerate the document using AI
Example:
await callTool({
name: "update_document",
arguments: {
documentType: "projectbrief",
content: "# Project Brief\n\n## Purpose\nTo develop an advanced and user-friendly AI..."
}
});query_memory_bankSearches across all documents with context-aware relevance ranking.
Parameters:
query (string): Search query (min 5 characters)
Example:
await callTool({
name: "query_memory_bank",
arguments: {
query: "system architecture components"
}
});export_memory_bankExports all Memory Bank documents.
Parameters:
format (enum, default: "folder"): Export format, either "json" or "folder"
outputPath (string, optional): Custom output path for the export
Example:
await callTool({
name: "export_memory_bank",
arguments: {
format: "json",
outputPath: "/Users/username/Documents/exports"
}
});Memory Bank organizes project knowledge into six core document types:
Project Brief (projectbrief.md): Core document defining project objectives, scope, and vision
Product Context (productContext.md): Documents product functionality from a user perspective
System Patterns (systemPatterns.md): Establishes system architecture and component relationships
Tech Context (techContext.md): Specifies technology stack and implementation details
Active Context (activeContext.md): Tracks current tasks, open issues, and development focus
Progress (progress.md): Documents completed work, milestones, and project history
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tuncer-byte/memory-bank-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
