MCP.so
Sign In
M

Memory Arbiter MCP Server

@billy12151

Basic information

About Memory Arbiter MCP Server

Share one memory store across all your AI coding tools. Memory Arbiter is a lightweight, fully local MCP Server with built-in dual-timeline conflict arbitration. No cloud, no LLM calls — just SQLite.

#memory#conflict-resolution#multi-agent#shared-memory#sqlite#local-first#mcp

Memory Arbiter MCP Server config

Add this server to your MCP-compatible client using the configuration below.

{
  "mcpServers": {
    "memory-arbiter": {
      "command": "memory-arbiter-mcp",
      "env": {
        "MEMORY_ARBITER_CLIENT": "zcode",
        "MEMORY_ARBITER_AGENT_ID": "zcode-default",
        "MEMORY_ARBITER_DB_PATH": "~/.local/share/memory-arbiter/memory.sqlite3"
      }
    }
  }
}

Memory Arbiter MCP Server tools

Tool list not available yet

This listing does not currently have a tool list to display. This does not mean the server has no tools; check its documentation for supported capabilities.

We auto-extract tools from the README. The maintainer can list them under a ## Tools heading to populate this section.

Overview

What is Memory Arbiter MCP?

Memory Arbiter MCP is a Model Context Protocol server that provides a shared local memory store, backed by SQLite, for multiple AI coding tools such as ZCode, Codex, Cursor, and Claude Code. It is designed for developers who need a consistent memory layer across different assistants without relying on cloud services.

How to use Memory Arbiter MCP?

Install the package with pip install memory-arbiter-mcp, then add it as an MCP server to each AI coding tool you use. The shared memory database is stored locally in an SQLite file; no additional infrastructure is required.

Key features of Memory Arbiter MCP

  • Shared memory store across multiple AI coding tools
  • Conflict arbitration with multi-factor resolution
  • User-confirmed memories locked from agent overwrites
  • Zero cloud dependencies, all local SQLite
  • Graceful degradation through fallback search methods

Use cases of Memory Arbiter MCP

  • Maintain a consistent knowledge base across different coding assistants
  • Preserve user-confirmed context that agents cannot accidentally overwrite
  • Resolve conflicting memory entries automatically during multi-agent workflows
  • Keep all memory data locally for privacy and offline usage
  • Fall back to simpler search methods when vector search is unavailable

Frequently asked questions

1

How does conflict arbitration work?

Conflicts are resolved using a dual-timeline priority: user-confirmed entries take precedence, then event time, source trust level, and finally ingest time.

2

Can agents overwrite memories I’ve confirmed?

No. User-confirmed memories are locked and cannot be overwritten by agents, ensuring critical context remains stable.

3

Does this server require cloud services or LLM calls?

No. Everything runs locally on SQLite with no cloud dependencies and zero LLM calls for memory operations.

4

What happens if sqlite-vec is not installed?

The server degrades gracefully through fallbacks: first FTS5, then LIKE queries, and finally reading from a JSONL backup.

5

How is the memory store shared between tools?

Each tool connects to the same MCP server, which reads and writes a single local SQLite database file.

Comments

More Memory & Knowledge MCP servers