Skip to main content
Glama
AliYar-Khan

light-agent-memory-mcp-server

by AliYar-Khan
README.md
# light-agent-memory-mcp-server

MCP server for persistent agent memory — projects, preferences, and session learnings stored in a local SQLite database.

**Harness-agnostic.** Works with any MCP-compatible client: opencode, Claude Desktop, Cursor, Windsurf, etc.

## Install

```bash
npm install -g light-agent-memory-mcp-server
```

Or use directly with npx (no install needed):

```bash
npx light-agent-memory-mcp-server
```

## Configure

Add to your MCP client's config:

**opencode** (`~/.config/opencode/opencode.json`):
```json
{
  "mcp": {
    "memory": {
      "type": "local",
      "command": ["npx", "-y", "light-agent-memory-mcp-server"],
      "enabled": true
    }
  }
}
```

**Claude Desktop** (`claude_desktop_config.json`):
```json
{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "light-agent-memory-mcp-server"]
    }
  }
}
```

**Cursor** (`.cursor/mcp.json`):
```json
{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "light-agent-memory-mcp-server"]
    }
  }
}
```

### Custom database path

```bash
npx light-agent-memory-mcp-server --db /path/to/custom.db
```

## Tools

### Project Memory

| Tool | Description |
|------|-------------|
| `memory_project_save` | Save/update project context (tech stack, architecture, conventions) |
| `memory_project_get` | Get project details by name |
| `memory_project_list` | List all saved projects |

### Preference Memory

| Tool | Description |
|------|-------------|
| `memory_pref_save` | Save/update a personal coding preference |
| `memory_pref_get` | Get a preference by key |
| `memory_pref_list` | List preferences (optionally filtered by category) |

### Learning Memory

| Tool | Description |
|------|-------------|
| `memory_learning_save` | Record a session learning (solution, insight, bug note) |
| `memory_learning_search` | Search learnings by keyword |

### Generic

| Tool | Description |
|------|-------------|
| `memory_save` | Unified save (auto-routes by type) |
| `memory_search` | Cross-type search by keyword |
| `memory_delete` | Delete a memory by type and ID |
| `memory_list` | List all memories with pagination and stats |

## Examples

**Save a project:**
```
memory_project_save({
  name: "my-app",
  path: "/home/user/projects/my-app",
  tech_stack: ["TypeScript", "React", "SQLite"],
  architecture: "Monorepo with pnpm workspaces, plugin-based architecture",
  conventions: "ESM-only, strict TypeScript, no comments in code"
})
```

**Save a preference:**
```
memory_pref_save({
  key: "language.typescript.style",
  value: "Always use ESM imports, strict mode, and prefer readonly types",
  category: "language"
})
```

**Record a learning:**
```
memory_learning_save({
  title: "Fix SQLite WAL mode deadlock",
  content: "When using WAL mode in SQLite, set busy_timeout to 5000ms to avoid SQLITE_BUSY errors under concurrent reads.",
  project_name: "my-app",
  tags: ["sqlite", "debugging", "concurrency"]
})
```

**Search all memories:**
```
memory_search({ query: "SQLite" })
```

## Database

Data is stored in `~/.agent-memory/memory.db` by default (SQLite via Node.js built-in `node:sqlite`). The database is created automatically on first run.

### Schema

- **projects** — `id`, `name` (unique), `path`, `tech_stack` (JSON), `architecture`, `conventions`, `notes`, timestamps
- **preferences** — `id`, `key` (unique), `value`, `category`, timestamps
- **learnings** — `id`, `title`, `content`, `project_name`, `tags` (JSON), timestamps

## Development

```bash
git clone https://github.com/AliYar-Khan/light-agent-memory-mcp-server.git
cd light-agent-memory-mcp-server
npm install
npm run build
npm run dev  # runs with tsx, no build step
```

## License

MIT

TDQS

A3.7/5.0

Scored across 12 tools

Disambiguation3/5

The type-specific tools (project/pref/learning) are fairly distinct, but the generic memory_save, memory_search, and memory_list overlap with specialized equivalents like memory_project_save, memory_learning_search, and memory_project_list. The descriptions clarify the generic vs. specific distinction, but an agent still faces multiple paths to accomplish the same operation.

Naming Consistency4/5

Tool names consistently use a memory_ prefix and mostly follow a memory_<type>_<action> pattern. Minor inconsistencies exist: 'search' is used for learning where 'list' or 'get' might be expected, and the top-level memory_save/memory_search/memory_delete/memory_list deviate from the type-specific naming pattern.

Tool Count4/5

Twelve tools is reasonable for a memory system covering projects, preferences, and learnings. The count is slightly inflated by the generic memory_* tools that duplicate type-specific functionality, but overall the server remains well-scoped and navigable.

Completeness4/5

The server covers create, read, list, search, and delete across all memory types, either through type-specific or generic tools. Minor gaps exist—learning has no direct get-by-ID function, and deletion is only exposed through the generic memory_delete—but common workflows can be completed with existing tools.

Maintenance

ActivityMaintained
ResponsivenessNo issues