메모리 뱅크는 팀이 구조화된 프로젝트 문서를 작성, 관리 및 액세스할 수 있도록 지원하는 MCP 서버입니다. 상위 목표부터 기술 세부 사항 및 일일 진행 상황에 이르기까지 프로젝트 지식의 다양한 측면을 담은 상호 연결된 마크다운 문서 세트를 생성하고 관리합니다.
AI 생성 문서 : Gemini API를 활용하여 포괄적인 프로젝트 문서를 자동으로 생성합니다.
구조화된 지식 시스템 : 계층 구조로 6가지 핵심 문서 유형을 유지합니다.
MCP 통합 : AI 어시스턴트와의 원활한 통합을 위한 모델 컨텍스트 프로토콜 구현
사용자 지정 가능한 위치 : 메모리 뱅크 디렉토리를 생성할 위치를 지정하세요.
문서 템플릿 : 프로젝트 간략 설명, 제품 컨텍스트, 시스템 패턴 등에 대한 사전 정의된 템플릿입니다.
AI 지원 업데이트 : 문서를 수동으로 업데이트하거나 AI 지원을 통해 다시 생성합니다.
고급 쿼리 : 컨텍스트 인식 관련성 순위를 사용하여 모든 문서 검색
Related MCP server: Gigaspec
지엑스피1
# 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 (enum): 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 (enum, 기본값: "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 ): 기술 스택 및 구현 세부 정보를 지정합니다.
Active Context ( activeContext.md ): 현재 작업, 미해결 문제 및 개발 초점을 추적합니다.
진행 상황 ( progress.md ): 완료된 작업, 이정표 및 프로젝트 내역을 문서화합니다.
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.
