Skip to main content
Glama
drdee

Memory MCP

by drdee

메모리 MCP

저수준 서버 구현과 SQLite 저장소를 사용하여 메모리를 저장하고 검색하기 위한 모델 컨텍스트 프로토콜 서버입니다.

설치

이 프로젝트에서는 pip 대신 uv를 사용하여 종속성을 관리합니다. uv는 빠르고 안정적인 Python 패키지 설치 및 확인 프로그램입니다.

uv를 사용하여 설치:

지엑스피1

또는 소스에서 직접 설치:

uv pip install .

개발을 위해:

uv pip install -e ".[dev]"

uv가 설치되어 있지 않다면 공식 지침 에 따라 설치할 수 있습니다.

Related MCP server: SQLite MCP Server

용법

서버 실행

memory-mcp

이렇게 하면 메모리를 저장하고 검색할 수 있는 MCP 서버가 시작됩니다.

사용 가능한 도구

메모리 MCP는 다음과 같은 도구를 제공합니다.

  • remember : 제목과 내용을 넣어 새로운 기억을 저장하다

  • get_memory : ID 또는 제목으로 특정 메모리를 검색합니다.

  • list_memories : 저장된 모든 메모리를 나열합니다

  • update_memory : 기존 메모리 업데이트

  • delete_memory : 메모리 삭제

MCP Inspect를 사용한 디버깅

MCP는 mcp inspect 라는 편리한 명령줄 도구를 제공하는데, 이를 통해 MCP 서버와 직접 디버깅하고 상호작용할 수 있습니다.

설정

  1. 먼저 MCP CLI 도구가 설치되어 있는지 확인하세요.

uv pip install mcp[cli]
  1. 한 터미널에서 메모리 MCP 서버를 시작합니다.

memory-mcp
  1. 다른 터미널에서 mcp inspect 사용하여 실행 중인 서버에 연결합니다.

mcp inspect

MCP Inspect 사용

연결되면 다음을 수행할 수 있습니다.

사용 가능한 도구 나열

> tools

이렇게 하면 메모리 MCP 서버에서 제공하는 모든 도구가 표시됩니다.

도구 호출

도구를 호출하려면 call 명령 다음에 도구 이름과 필요한 인수를 사용합니다.

> call remember title="Meeting Notes" content="Discussed project timeline and milestones."
> call list_memories
> call get_memory memory_id=1
> call update_memory memory_id=1 title="Updated Title" content="Updated content."
> call delete_memory memory_id=1

디버그 모드

디버그 모드를 활성화하면 자세한 요청 및 응답 정보를 볼 수 있습니다.

> debug on

이를 통해 서버로 어떤 데이터가 전송되고, 서버에서 어떤 데이터가 수신되는지 정확히 파악할 수 있습니다.

도구 스키마 탐색

특정 도구에 대한 스키마를 보려면:

> tool remember

여기에는 도구에 대한 입력 스키마, 필수 매개변수 및 설명이 표시됩니다.

문제 해결

문제가 발생하는 경우:

  1. 서버가 실행 중인 터미널의 서버 로그를 확인하여 오류 메시지가 있는지 확인하세요.

  2. MCP 검사 터미널에서 디버그 모드를 활성화하고 debug on 원시 요청과 응답을 확인하세요.

  3. 도구 매개변수가 예상 스키마와 일치하는지 확인합니다( tool 명령으로 확인).

  4. 서버가 충돌하는 경우 서버 터미널에서 처리되지 않은 예외가 있는지 확인하세요.

개발

프로젝트에 기여하려면 개발 종속성을 설치하세요.

uv pip install -e ".[dev]"

종속성 관리

이 프로젝트에서는 uv.lock 파일을 사용하여 종속성을 잠급니다. 종속성을 업데이트하려면 다음을 수행하세요.

uv pip compile pyproject.toml -o uv.lock

테스트 실행

python -m pytest

코드 포맷팅

black memory_mcp tests

린팅

ruff check memory_mcp tests

유형 검사

mypy memory_mcp

Available Tools

5 tools
delete_memoryC

Delete a memory.

ParametersJSON Schema
NameRequiredDescriptionDefault
memory_idYesThe ID of the memory to delete

TDQS

C2.7/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. 'Delete a memory' implies a destructive, irreversible mutation, but it doesn't specify permissions required, whether deletion is permanent or recoverable, error handling (e.g., if memory_id doesn't exist), or side effects. This is a significant gap for a destructive tool 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 extremely concise at three words, with zero wasted text. It's front-loaded with the core action, making it easy to parse quickly. Every word earns its place by directly stating the tool's function without redundancy.

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 this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context like what happens post-deletion (e.g., confirmation message, error responses), prerequisites, or how it differs from sibling tools. The agent lacks sufficient information to use this tool safely and effectively.

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%, with the parameter 'memory_id' clearly documented in the schema as 'The ID of the memory to delete'. The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 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.

Purpose3/5

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

The description 'Delete a memory' clearly states the verb (delete) and resource (memory), making the basic purpose understandable. However, it doesn't differentiate this tool from its sibling 'update_memory' which could also modify memory state, nor does it specify what type of memory is being deleted (e.g., user memory, system memory, cached data). It's adequate but vague about scope.

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. With siblings like 'get_memory', 'list_memories', 'remember', and 'update_memory', there's no indication of when deletion is appropriate (e.g., after retrieval, as cleanup, or for specific memory types). The agent must infer usage from the tool name alone.

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

get_memoryC

Retrieve a specific memory by ID or title.

ParametersJSON Schema
NameRequiredDescriptionDefault
memory_idNoThe ID of the memory to retrieve
titleNoThe title of the memory to retrieve

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries full burden but lacks behavioral details. It states the tool retrieves but doesn't disclose error handling (e.g., if memory doesn't exist), authentication needs, rate limits, or return format. The description is minimal and doesn't compensate for the absence of annotations, leaving key operational traits unclear.

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 ('Retrieve a specific memory') and adds necessary qualification ('by ID or title'). There is zero waste, and every word earns its place, making it appropriately sized for a simple retrieval tool.

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 moderate complexity (retrieval with two parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like error cases or return values, leaving gaps that could hinder an AI agent's ability to use it correctly. More context is needed for a retrieval operation.

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 already documents both parameters ('memory_id' and 'title') fully. The description adds no extra meaning beyond implying these are alternative lookup methods, but doesn't explain exclusivity, precedence, or format details. This meets the baseline of 3 when schema coverage is high.

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 ('Retrieve') and resource ('a specific memory'), and specifies the lookup methods ('by ID or title'). It distinguishes from siblings like 'list_memories' (which retrieves multiple) and 'delete_memory'/'update_memory' (which modify). However, it doesn't explicitly contrast with 'remember' (which likely creates memories), keeping it from a perfect 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., needing an existing memory), exclusions (e.g., not for bulk retrieval), or direct comparisons to siblings like 'list_memories' for multiple memories or 'remember' for creation. Usage is implied but not articulated.

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

list_memoriesB

List all stored memories.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/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 'List all stored memories,' which implies a read-only operation, but doesn't clarify aspects like pagination, sorting, filtering, or what 'all' entails (e.g., if there are limits). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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 'List all stored memories' is a single, efficient sentence that front-loads the core action and resource. It wastes no words and is appropriately sized for a simple tool, earning the highest score for conciseness.

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 minimally adequate. It states what the tool does but lacks details on behavior (e.g., output format, limitations) that would be helpful for an agent. Without annotations or output schema, more context is needed for full 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 the schema fully documents the absence of inputs. The description doesn't add parameter details, but since there are no parameters, a baseline of 4 is appropriate—it's clear no inputs are needed, though a perfect score would require explicit confirmation of this in the description.

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 'List all stored memories' clearly states the verb ('List') and resource ('stored memories'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_memory' (which likely retrieves a specific memory) or 'remember' (which likely creates a memory), so it doesn't reach the highest score.

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. Given siblings like 'get_memory' (for specific retrieval) and 'delete_memory'/'update_memory' (for modifications), the agent must infer usage from the name alone, which is insufficient for optimal tool selection.

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

rememberC

Store a new memory.

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYesThe full content of the memory to store
titleYesA concise title for the memory

TDQS

C2.9/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. 'Store a new memory' implies a write operation, but it doesn't specify whether this is idempotent, requires authentication, has side effects, or what happens on failure. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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 ('Store a new memory') that is front-loaded and wastes no words. It directly conveys the core action without unnecessary elaboration, 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 that this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, potential errors, or how it interacts with sibling tools like 'list_memories'. For a tool that modifies state, more context is needed to guide effective usage.

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 schema description coverage is 100%, with clear descriptions for both parameters ('content' and 'title'). The tool description adds no additional parameter information beyond what's in the schema, so it meets the baseline score of 3 where the schema does the heavy lifting without extra value from the description.

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 'Store a new memory' clearly states the verb ('store') and resource ('memory'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'update_memory' or 'delete_memory' beyond the 'new' qualifier, which is why it doesn't reach the highest score.

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 like 'update_memory' or 'delete_memory'. It lacks any context about prerequisites, such as whether this creates a memory from scratch versus modifying existing ones, leaving the agent to infer usage from the tool name alone.

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

update_memoryC

Update an existing memory.

ParametersJSON Schema
NameRequiredDescriptionDefault
contentNoOptional new content for the memory
memory_idYesThe ID of the memory to update
titleNoOptional new title for the memory

TDQS

C2.7/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 tool updates an existing memory but doesn't clarify whether this is a destructive operation, what permissions are required, how conflicts are handled, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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 with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration. Every word earns its place, 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 tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It doesn't explain what 'update' entails (e.g., partial vs. full updates), error conditions, or return values. For a tool that modifies data, more context is needed to ensure correct usage by an AI agent.

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 already documents all three parameters (memory_id, content, title) with their types and optionality. The description adds no additional meaning beyond the schema, such as format constraints or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose3/5

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

The description 'Update an existing memory' clearly states the verb (update) and resource (memory), but it's vague about what constitutes a 'memory' and doesn't differentiate from sibling tools like 'remember' or 'delete_memory'. It's better than a tautology but lacks specificity about the update operation's scope.

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 like 'delete_memory' or 'remember'. It doesn't mention prerequisites (e.g., needing an existing memory ID) or contextual cues for choosing this tool over others. The absence of usage instructions leaves the agent without decision-making help.

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. 5 tool updatesv1.0.0
    • First observeddelete_memory
    • First observedget_memory
    • First observedlist_memories
    • First observedremember
    • First observedupdate_memory

TDQS

A3.5/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific CRUD operations on memories: list (retrieve all), get (retrieve specific), remember (create), update (modify), and delete (remove). There is no overlap in functionality, making tool selection unambiguous for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case, using clear action verbs (list, get, remember, update, delete) paired with the noun 'memory'. There are no deviations or mixed conventions, ensuring predictable naming throughout.

Tool Count5/5

With 5 tools, this server is well-scoped for memory management, providing complete CRUD coverage without unnecessary bloat. Each tool earns its place by covering essential operations, making the count appropriate for the domain.

Completeness5/5

The tool set offers complete CRUD/lifecycle coverage for memory management: create (remember), read (list_memories, get_memory), update (update_memory), and delete (delete_memory). There are no obvious gaps, allowing agents to handle all core workflows without dead ends.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • -
    license
    Not graded
    quality
    A
    maintenance
    A Model Context Protocol (MCP) server implementation that provides database interaction and business intelligence capabilities through SQLite. This server enables running SQL queries, analyzing business data, and automatically generating business insight memos.
    91,276
    MIT
  • A
    license
    B
    quality
    C
    maintenance
    A Model Context Protocol server that enables SQL operations (SELECT, INSERT, UPDATE, DELETE) and table management through a standardized interface with SQLite databases.
    7
    43 npm
    1
    ISC