Skip to main content
Glama
enesjakozh
IncomeStreamSurfer

Roo Code Memory Bank MCP Server

by IncomeStreamSurfer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Roo 코드 메모리 뱅크 MCP 서버

이 프로젝트는 Roo 코드 메모리 뱅크 시스템의 핵심 기능을 모델 컨텍스트 프로토콜(MCP) 서버로 구현합니다. 이를 통해 AI 어시스턴트는 구조화된 MCP 도구를 사용하여 파일 기반 메모리 뱅크와 상호 작용함으로써 세션 전반에 걸쳐 프로젝트 컨텍스트를 유지할 수 있습니다.

특징

이 MCP 서버는 다음과 같은 도구를 제공합니다.

  • initialize_memory_bank : 초기 템플릿을 사용하여 memory-bank/ 디렉토리와 표준 .md 파일( productContext.md , activeContext.md , progress.md , decisionLog.md , systemPatterns.md )을 생성합니다.

    • 입력 : (선택 사항) { "project_brief_content": string }

    • 출력 : { "status": "success" | "error", "messages"?: string[], "message"?: string }

  • check_memory_bank_status : memory-bank/ 디렉토리가 존재하는지 확인하고 그 안에 있는 .md 파일을 나열합니다.

    • 입력 : {}

    • 출력 : { "exists": boolean, "files": string[] }

  • read_memory_bank_file : 지정된 메모리 뱅크 파일의 전체 내용을 읽습니다.

    • 입력 : { "file_name": string }

    • 출력 : { "content": string } 또는 오류 객체.

  • append_memory_bank_entry : 지정된 파일에 타임스탬프가 있는 새 항목을 추가합니다. 선택적으로 특정 마크다운 헤더 아래에 추가할 수 있습니다. 파일이 없으면 새로 생성합니다.

    • 입력 : { "file_name": string, "entry": string, "section_header"?: string }

    • 출력 : { "status": "success" | "error", "message": string }

Related MCP server: engrams

필수 조건

  • Node.js(v18 이상 권장)

  • npm(일반적으로 Node.js에 포함됨)

  • MCP 서버를 관리하고 실행할 수 있는 MCP 클라이언트 환경(클라인이 사용하는 환경과 유사)

설치

  1. 저장소를 복제합니다.

    지엑스피1

  2. 종속성 설치:

    npm install

  3. 프로젝트를 빌드하세요:

    npm run build

    이렇게 하면 TypeScript 코드가 dist/ 디렉토리의 JavaScript로 컴파일됩니다.

구성(Cline MCP 클라이언트용)

이 서버를 AI 비서(예: Cline)가 사용할 수 있게 하려면 해당 구성을 MCP 설정 파일(예: cline_mcp_settings.json )에 추가해야 합니다.

설정 파일에서 mcpServers 객체를 찾아 다음 항목을 추가하세요.

{
  "mcpServers": {
    // ... other server configurations ...

    "roo-code-memory-bank-mcp": {
      "autoApprove": [
        "initialize_memory_bank",
        "check_memory_bank_status",
        "read_memory_bank_file",
        "append_memory_bank_entry"
      ],
      "disabled": false,
      "timeout": 60,
      "command": "node", // Or "cmd.exe" with "/c node ..." on Windows if needed
      "args": [
        // IMPORTANT: Replace this path with the actual absolute path
        // to the compiled index.js file on your system
        "/path/to/your/cloned/repo/roo-code-memory-bank-mcp-server/dist/index.js"
      ],
      "env": {},
      "transportType": "stdio"
    }

    // ... other server configurations ...
  }
}

중요: /path/to/your/cloned/repo/ 컴퓨터에서 저장소를 복제한 경로의 올바른 절대 경로로 바꾸세요. 경로 구분 기호가 운영 체제에 맞는지 확인하세요(예: Windows에서는 백슬래시 \ 사용).

서버 실행

일반적으로 서버를 수동으로 실행할 필요는 없습니다. MCP 클라이언트(Cline 등)는 해당 도구 중 하나를 처음 호출할 때 구성 파일에 지정된 command 과 args 사용하여 서버를 자동으로 시작합니다.

수동으로 테스트하려면 프로젝트 디렉토리에서 npm start 실행하면 됩니다.

용법

AI 비서는 정의된 도구를 사용하여 서버와 상호 작용합니다. 일반적인 워크플로는 다음과 같습니다.

  1. 메모리 뱅크 상태 확인( check_memory_bank_status ).

  2. 필요한 경우 초기화합니다( initialize_memory_bank ).

  3. 관련 파일을 읽어서( read_memory_bank_file ) 컨텍스트를 파악합니다.

  4. 결정이 내려지거나 진행이 진행됨에 따라 항목을 추가합니다( append_memory_bank_entry ).

memory-bank/ 디렉토리는 서버 프로세스가 시작되는 디렉토리와 동일한 디렉토리에 생성됩니다(MCP 클라이언트 구성을 통해 시작할 경우 이 프로젝트 디렉토리의 루트여야 함).

사용자 정의 지침

이 지침을 Roo 내부에 설정하세요

필요한 경우 MCP를 사용해야 합니다.

특정 MCP 흐름이 있습니다.

context7을 사용하여 이 프로세스에 필요한 관련 문서를 찾고, 관련 지식을 관련 하위 작업에 제공해야 합니다. 무언가 불확실한 경우 항상 context7을 사용하여 중요한 문서를 조사하세요. Google Maps MCP를 사용하여 + -를 검색하세요. 이렇게 하면 작업을 수행하는 데 필요한 기본적인 업체를 찾을 수 있습니다. Brave Search MCP를 사용하여 스크래핑할 URL을 찾으세요. fetch_txt 및 fetch_markdown과 함께 fetch MCP를 사용하여 페이지에서 텍스트와 이미지를 찾아 JSON 파일로 변환하고 심층적인 내용을 만드세요. Openrouter 검색을 사용하여 주제, 리뷰 등에 대한 일반적인 감정을 찾으세요.

프로젝트 컨텍스트를 유지하려면 roo-code-memory-bank-mcp 서버를 활용하세요.

  • 작업이나 중요한 하위 작업을 시작할 때 check_memory_bank_status 사용합니다.

  • 메모리 뱅크가 존재하는 경우( exists: true ), 관련 파일(예: productContext.md , activeContext.md )에 대해 read_memory_bank_file 사용하여 현재 프로젝트 컨텍스트를 로드합니다.

  • 이러한 맥락을 계획과 실행에 통합하세요.

  • 중요한 결정, 진행 상황 업데이트 또는 아키텍처 변경을 할 때 append_memory_bank_entry 사용하여 해당 파일( decisionLog.md , progress.md 등)에 정보를 기록하여 컨텍스트 지속성을 보장합니다.

  • 메모리 뱅크가 존재하지 않는 경우 프로젝트에 적합하다면 initialize_memory_bank 사용하는 것을 고려하세요.

Available Tools

4 tools
append_memory_bank_entryC

Appends a new, timestamped entry to a specified file, optionally under a specific markdown header.

ParametersJSON Schema
NameRequiredDescriptionDefault
entryYesThe content of the entry to append.
file_nameYesThe name of the memory bank file to append to.
section_headerNo(Optional) The exact markdown header (e.g., '## Decision') to append under.

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the tool appends with timestamping and optional header placement, but lacks details on permissions, file format constraints, error handling (e.g., if file doesn't exist), or mutation effects (e.g., overwriting). This is inadequate for a write operation with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core action and key optional feature. Every word earns its place, with no redundancy or fluff, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a write operation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error cases, return values, or interaction with siblings, leaving significant gaps for an agent to use it correctly in context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds marginal value by clarifying that 'section_header' is for markdown headers and 'entry' is content, but doesn't provide syntax examples or constraints beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Appends'), resource ('to a specified file'), and key details ('new, timestamped entry', 'optionally under a specific markdown header'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'initialize_memory_bank' (which likely creates files) or 'read_memory_bank_file' (which reads content), missing full sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., file must exist), exclusions (e.g., not for creating new files), or comparisons to siblings like 'initialize_memory_bank' for setup or 'read_memory_bank_file' for retrieval, leaving usage context implied at best.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_memory_bank_statusA

Checks if the memory-bank directory exists and lists the .md files within it.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's actions (checking directory existence and listing .md files), which is helpful, but doesn't cover aspects like error handling (e.g., what happens if the directory doesn't exist), performance characteristics, or output format details. This leaves gaps in understanding how the tool behaves in edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded with the main action ('Checks if...') and includes all relevant details (directory existence and file listing) in a compact form, making it easy to understand at a glance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is somewhat complete but could be improved. It explains what the tool does, but without an output schema, it doesn't detail the return format (e.g., whether it returns a boolean, list, or structured data). For a status-checking tool, more information on output behavior would enhance completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. Since there are no parameters to explain, this meets expectations, but a perfect score is reserved for cases where the description adds value beyond an already complete schema, which isn't applicable here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('checks if... exists' and 'lists... files') and identifies the resource ('memory-bank directory' and '.md files'). It distinguishes from siblings by focusing on status checking rather than appending, initializing, or reading specific files. However, it doesn't explicitly contrast with sibling tools, keeping it from a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by mentioning what the tool does (checking existence and listing files), which suggests it's for verifying the memory bank's state. However, it lacks explicit guidance on when to use this tool versus alternatives like 'initialize_memory_bank' or 'read_memory_bank_file', and doesn't specify any prerequisites or exclusions, leaving usage decisions somewhat ambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

initialize_memory_bankB

Creates the memory-bank directory and standard .md files with initial templates.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_brief_contentNo(Optional) Content from projectBrief.md to pre-fill productContext.md

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states the tool creates directories and files, it doesn't cover critical aspects such as whether this is idempotent (e.g., what happens if the memory bank already exists), permission requirements, error conditions, or side effects. This is a significant gap for a tool that performs file system operations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's action without unnecessary words. It's front-loaded with the core purpose and avoids redundancy, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (file system creation with templates), lack of annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but misses behavioral details like idempotency or error handling. With no structured fields to rely on, the agent would need more information for robust usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with one optional parameter clearly documented. The description doesn't add any parameter-specific information beyond the schema, but since schema coverage is high and there's only one parameter, the baseline is 3. The description's mention of 'initial templates' provides slight additional context about the tool's behavior, justifying a score of 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Creates the memory-bank directory and standard .md files with initial templates.' This specifies the verb ('Creates') and resources ('memory-bank directory and standard .md files'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'check_memory_bank_status' or 'read_memory_bank_file', which would require a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the memory bank must not already exist), exclusions, or comparisons to siblings like 'append_memory_bank_entry'. This leaves the agent with minimal context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_memory_bank_fileC

Reads the full content of a specified memory bank file.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_nameYesThe name of the memory bank file (e.g., 'productContext.md')

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Reads') but lacks details on permissions, error handling (e.g., what happens if the file doesn't exist), or output format (e.g., plain text, structured data). This leaves significant gaps for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like error cases or output format, which are crucial for a read operation. The high schema coverage helps with parameters, but overall context is insufficient for reliable tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the parameter 'file_name' well-documented in the schema itself. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Reads') and resource ('full content of a specified memory bank file'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'check_memory_bank_status' or 'append_memory_bank_entry', which might involve reading or checking content in different ways.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify if this should be used for retrieving entire files versus checking status or appending entries, leaving the agent to infer usage from tool names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv1.0.0
    • First observedappend_memory_bank_entry
    • First observedcheck_memory_bank_status
    • First observedinitialize_memory_bank
    • First observedread_memory_bank_file
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: append adds entries, check verifies directory status, initialize sets up the structure, and read retrieves content. There is no overlap in functionality, making it easy for an agent to select the correct tool without confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., append_memory_bank_entry, check_memory_bank_status), with clear and descriptive verbs. There are no deviations in naming conventions, ensuring predictability and readability.

Tool Count5/5

With 4 tools, the server is well-scoped for managing a memory bank system. Each tool serves a distinct and necessary function (setup, verification, reading, writing), and the count is neither too sparse nor excessive for the domain.

Completeness4/5

The tools cover core CRUD-like operations for a memory bank: initialize (create), check (status), read (retrieve), and append (update/add). A minor gap is the lack of a delete or modify tool for removing or editing entries, but agents can work around this with append for updates.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches