Skip to main content
Glama
deenesjakoruzh
fangsylar-pixel

Marvis Working Memory MCP

by fangsylar-pixel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Marvis Working Memory MCP

A local, persistent working-memory MCP that lets agents read rules, preferences, and project state before every task, and distill reusable experience after successful tasks.

Works with clients that support stdio MCP, including Marvis, as well as local agent frameworks that can connect to MCP. All data is stored locally in memory.json and is never uploaded to the cloud.

What it solves

  • Prevents agents from forgetting confirmed work rules and preferences in new conversations.

  • Lets project progress, todos, and key decisions be restored in later tasks.

  • Turns successful debugging paths into experience, prioritized for reuse in similar tasks next time.

Related MCP server: memkit

Import into Marvis

Add the following to Marvis's MCP configuration:

{
  "mcpServers": {
    "working-memory": {
      "command": "node",
      "args": ["C:\\path\\to\\marvis-memory-mcp\\server.js"]
    }
  }
}

Add to Marvis's global rules

Put the following text at the beginning of Marvis's global instructions, assistant rules, or every automated task template:

你拥有 working-memory MCP。执行任何实质任务前，必须先调用 load_context：传入当前项目名和任务关键词。先依据返回的固定规则、长期偏好、项目状态和相关记忆规划与执行；若信息缺失或冲突，先向用户确认。

仅当用户明确确认某项长期偏好、规则、关键决定、事实或待办时，调用 remember，并传 confirmed: true；不得把你的推测写入记忆。任务出现稳定进展时调用 update_project。每个任务结束前必须调用 close_task，记录结果和下一步。

当任务最终成功、或解决了过程中出现的问题时，必须调用 record_experience：写入最终验证成功的步骤，以及“问题—解决方式”。下次相近任务开始时，使用任务关键词调用 load_context 并优先复用这些已验证经验。不得存储密码、验证码、访问令牌或私密个人数据。

Tools

Tool

When to call

load_context

Before every task starts

remember

After the user explicitly confirms information should be kept long-term

update_project

When project state changes in a stable way

close_task

Before every task ends

record_experience

After a task succeeds, especially after debugging

First use

On first use, have Marvis record your work preferences and rules with remember, passing confirmed: true. Then, the first time each project runs, use update_project to establish project state. The data file can be backed up manually; it's recommended to make a copy before modifying it.

Important boundaries

  • MCP provides stable read/write capabilities, but it cannot force Marvis to call it on its own; the "must call" constraints in global rules or task templates are still necessary.

  • What is stored here is reviewable structured text; full chat logs are not saved.

Development

Requires Node.js 18 or higher. The project has no third-party dependencies:

node server.js

On first launch, a local memory.json is created automatically. The file is excluded via .gitignore to avoid committing personal memory to the repository.

License

MIT

Available Tools

5 tools
close_taskB

每个任务结束前调用，记录结果与待办，供下一次任务开始时加载。

ParametersJSON Schema
NameRequiredDescriptionDefault
outcomeYes
projectYes
next_actionsNo

TDQS

B3.2/5.0
Behavior2/5

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

没有注解，描述承担全部责任。它只说了'记录'，但未说明是否覆盖已有数据、是否持久化、是否需要权限等。对于一个写操作而言，行为细节不足。

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

Conciseness4/5

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

描述是一句简洁的中文句子，没有冗余信息，直接点明用途和时机。虽然简短，但信息密度高。

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?

工具较为简单，3个参数，无输出模式。描述提供了基本使用时机，但参数细节和副作用说明不足，对于代理正确调用已足够基础，但仍缺乏关键上下文。

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

Parameters2/5

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

schema描述覆盖率为0%，描述提到了'结果'和'待办'，对应outcome和next_actions，但未提及必填参数project。描述只补偿了部分参数，没有完整解释所有输入。

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?

描述明确了工具的使用时机（任务结束前）和目的（记录结果与待办），动作与资源清晰。虽然名字是close_task，描述没有直接说'关闭'，而是强调保存上下文，但仍然能与兄弟工具区分。

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

Usage Guidelines4/5

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

明确规定了'每个任务结束前调用'，提供了具体的使用场景。虽然没有显式排除其他工具，但上下文足够清晰，暗示了与load_context的衔接关系。

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

load_contextA

每个任务开始时必须先调用。读取用户长期偏好、固定规则、指定项目状态与相关已确认记忆。

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNo本次任务的关键词，用于筛选相关记忆。
projectNo当前项目名称；没有项目可省略。

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations present, the description carries the burden of behavioral disclosure. It clearly states that the tool reads existing stored context rather than modifying it ('读取'), and it enumerates the kinds of data returned: preferences, rules, project status, and confirmed memories. It does not detail failure modes or return formatting, but the core read-only behavior is transparent.

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 two short sentences with no wasted words. The mandatory call-time instruction is front-loaded, followed immediately by a compact list of what is loaded. Every clause contributes essential information.

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

Completeness4/5

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

For a low-complexity tool with no required parameters and no output schema, the description covers when to call it, what it loads, and which optional parameter matters for project context. It does not explicitly describe the result format, but the 'loads context' semantics make the return behavior reasonably inferable.

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 baseline is 3. The description only loosely maps to the parameters ('关键词' to query and '指定项目' to project) and adds limited meaning beyond the schema, such as implying the project parameter is used to load project status. No additional syntax or filtering details are provided.

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

Purpose5/5

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

The description identifies a specific action ('读取'/'loads') and a concrete resource: user long-term preferences, fixed rules, project status, and confirmed memories. It also states an explicit usage role ('must be called at the start of every task'), clearly separating it from the write-oriented sibling tools like remember and record_experience.

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

Usage Guidelines4/5

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

The description gives explicit timing guidance: '每个任务开始时必须先调用' ('must be called first at the start of every task'). It does not explicitly discuss exclusions or alternatives, but the mandatory position and read-only nature make the intended usage clear relative to the sibling tools.

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

record_experienceA

当任务在遇到问题后最终成功，或首次验证一条可复用流程后调用。保存成功步骤和问题解决方式；同一项目、同一任务会更新为最新经验。不得记录密码、验证码、访问令牌、个人隐私或其他秘密。

ParametersJSON Schema
NameRequiredDescriptionDefault
taskYes可被下次同类任务匹配的清晰任务名称。
projectNo
problems_and_fixesNo出现过的问题及最终解决方式；无则传空数组。
successful_workflowYes最终验证成功的操作步骤。

TDQS

A4.7/5.0
Behavior4/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. It discloses that repeated calls for the same project+task overwrite the previous experience (update semantics), and it explicitly forbids recording sensitive data. It doesn't note failure modes or that calls may overwrite irreversibly, but the core behavioral traits are covered.

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?

A single dense sentence that front-loads the trigger conditions, then states the purpose, update behavior, and security constraint. No filler, every clause earns its place.

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

Completeness5/5

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

For a record/update tool with no output schema and 4 parameters (2 required), the description covers when to call, what it stores, update semantics, and prohibited content. The schema provides param types and descriptions; nothing essential is missing.

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?

Schema covers 75% of params with descriptionscars (task, successful_workflow, problems_and_fixes have descriptions; only project lacks one). The description adds important semantics: it explains the update key (project + task) and warns not to include secrets, which meaningfully supplements the schema. Adequate value beyond the schema.

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

Purpose5/5

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

The description states a specific verb (record), the resource (experience), and the exact trigger conditions (after problems with eventual success, or when validating a reusable workflow). It distinguishes itself from sibling tools like remember and update_project by framing a persistent, deduplicating experience store tied to task+project.

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

Usage Guidelines5/5

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

Explicitly states when to call: after a task succeeds following problems, or upon first validating a reusable workflow. It also gives a negative rule (what not to record: secrets), which effectively tells the agent when NOT to use it. This is clear, actionable guidance without needing to read the siblings.

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

rememberB

保存用户明确确认的长期偏好、规则、关键决定、事实、待办或笔记。不要保存模型推测；必须传 confirmed: true。

ParametersJSON Schema
NameRequiredDescriptionDefault
typeYes
contentYes
projectNo
confirmedYes

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It reveals that only confirmed information should be saved and that unconfirmed data is not stored, which is useful. However, it doesn't explain what happens to existing entries with the same name or content (overwrite vs. append), or the persistence scope (session vs. long-term), which are important behavioral traits for a memory tool.

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

Conciseness4/5

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

The description is a single concise sentence with a clear instruction followed by a critical constraint. It front-loads the purpose and gives a direct command. No wasted words, but the lack of structure (e.g., bullet points) is fine for a short description. The constraint is placed after the purpose, which is effective.

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?

For a tool with 4 parameters, no output schema, and no annotations, the description covers the core purpose and the key requirement (confirmed: true). It includes the enum values for 'type' implicitly, but leaves out details like how the tool handles duplicates, the nature of 'project' (optional?), and what the return value is. It's sufficient for basic use but lacks depth for edge cases.

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 coverage is 0%, so the description must compensate. It explains the 'confirmed' parameter (must be true) and lists the possible 'type' values in the description, but doesn't clarify the meaning of 'content' or 'project'. The enum for 'type' is in the schema, but the description repeats it in natural language, adding some redundancy. The description adds value for 'confirmed' but not much for other parameters.

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 stores long-term preferences, rules, decisions, facts, todos, or notes, with a specific requirement that they be user-confirmed. It distinguishes itself from siblings like load_context (retrieval) and record_experience (experience) by focusing on explicit user confirmations. However, it doesn't explicitly name the siblings, but the verb 'remember' and the listed content types provide sufficient clarity.

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 when to use: when the user has explicitly confirmed a fact or preference, and warns not to save model speculation. It provides a clear condition (confirmed: true) but doesn't explicitly contrast with alternatives like 'record_experience' or 'update_project'. The context is implied rather than spelled out, so it's adequate but not explicit.

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

update_projectA

更新当前项目的状态、摘要与下一步；适合任务进行中出现稳定进展时调用。

ParametersJSON Schema
NameRequiredDescriptionDefault
statusYes
projectYes
summaryNo
next_actionsNo

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations, the description must shoulder the burden of behavioral transparency, but it only restates the basic action (update status, summary, next steps) without disclosing side effects, idempotency, or handling of omitted optional fields. It does not mention permissions, rate limits, or error behavior, leaving significant gaps for a mutation tool.

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, front-loaded sentence that states the action first and a usage condition second, with no redundant words. It is concise and well-structured.

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 and lack of output schema, the description covers the core action and a usage trigger, but it does not explain behavior when optional parameters are omitted, inter-tool dependencies, or error conditions. It is minimally adequate but leaves room for more 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 0%, so the description's mention of 'status, summary, and next steps' helps map the generic parameter names (status, summary, next_actions) to domain concepts. However, it omits the 'project' parameter and does not clarify value formats or constraints, partially compensating for the schema's lack of detail.

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 updates the current project's status, summary, and next steps, using a specific verb and resource. It does not explicitly differentiate from sibling tools, but the purpose is unambiguous and the usage hint adds clarity.

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

Usage Guidelines4/5

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

The description provides a clear contextual condition: 'suitable to call when there is stable progress during a task.' This gives a when-to-use hint, though it does not list exclusions or alternative tools. The guidance is direct but lacks explicit comparison to siblings.

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 observedclose_task
    • First observedload_context
    • First observedrecord_experience
    • First observedremember
    • First observedupdate_project
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.7/5.0

Scored across 5 tools

Disambiguation4/5

Each tool targets a distinct memory lifecycle stage: load, save confirmed memory, update project state, close task, and record experience. Some overlap exists between saving todos in remember and close_task, and between update_project and close_task, but descriptions clarify the intended use cases.

Naming Consistency4/5

Most tools follow a clear verb_noun pattern: load_context, update_project, close_task, record_experience. The tool 'remember' breaks the pattern slightly by being a bare verb, but it is still recognizable and consistent in style.

Tool Count5/5

Five tools is well-scoped for a working memory server. Each tool covers a distinct lifecycle need without redundancy or bloat.

Completeness3/5

The core lifecycle is covered: load context, save memories, update project state, close tasks, and record experiences. However, there is no explicit way to delete or update an already saved memory, which could create dead ends when memories become obsolete or incorrect.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • memkit

    iamanishx
    A
    license
    Not graded
    quality
    D
    maintenance
    A fully local, persistent memory layer for AI agents that runs as an MCP stdio server and provides an AI SDK adapter for seamless integration with generateText/streamText agents.
    3 npm
    1
    MIT

  • memex

    kioie
    A
    license
    Not graded
    quality
    B
    maintenance
    Provides long-term local memory for AI coding agents via MCP, enabling persistent recall of preferences and project facts across chat sessions.
    1
    MIT

  • light-agent-memory-mcp-server

    AliYar-Khan
    A
    license
    A
    quality
    B
    maintenance
    Provides persistent, searchable memory for AI agents across any MCP-compatible client, storing project context, user preferences, and session learnings locally in SQLite with tools to save, retrieve, search, and manage them.
    12
    5 npm
    MIT