Skip to main content
Glama
agentage

@agentage/mcp-memory

Official
by agentage
README.md
# @agentage/server-memory

The **MCP server** for agentage Memory exposes your local vaults
(`~/.agentage/vaults.json`, read through [`@agentage/memory-core`](https://github.com/agentage/memory-core))
as the frozen 6 `memory__*` tools over stdio. The open, cross-vendor counterpart to
`@modelcontextprotocol/server-memory`.

This package is intentionally **small** - it is just the MCP definition (the 6-tool Zod
schema + `.mcpc.json`, the text renderer, `createMemoryServer`, and a ~15-line stdio bin).
All memory logic (backends, git, search, routing) lives in `@agentage/memory-core`.

## Use it

```bash
# one-time, offline: scaffold ~/.agentage + a starter vault
#   (memory-core's `init`, also surfaced by the agentage CLI)
npx @agentage/server-memory          # serves ~/.agentage/vaults.json over stdio
```

Point any stdio MCP client (Windsurf, Zed, Claude Desktop) at `npx @agentage/server-memory`.

## Reused by the CLI daemon

The server builder is transport-agnostic, so the agentage CLI reuses the exact same
pieces and only swaps the transport:

```ts
import { createMemoryServer, loadLocalServer } from '@agentage/server-memory';

// stdio bin:        await (await loadLocalServer()).connect(new StdioServerTransport());
// CLI daemon:       const server = createMemoryServer(registry, { scope: 'local' });
//                   await server.connect(new StreamableHTTPServerTransport(...));
```

## Develop

```bash
npm install        # links @agentage/memory-core via file:../memory-core
npm test           # vitest: contract (tools/list = 6) + tools (in-memory) + e2e (init -> spawned bin -> round-trip)
npm run verify     # type-check + lint + format:check + test + build
```

`@agentage/memory-core` is a local `file:` link until both packages publish to npm; build
core before running here (the e2e does this automatically). The 6-tool schema and
`.mcpc.json` snapshot are the frozen MCP contract - keep them in sync if the contract changes.

TDQS

A4.5/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a unique, well-defined purpose: create/overwrite (write), modify existing (edit), delete (delete), read by path (read), browse folder tree (list), and keyword search (search). No overlapping functionality.

Naming Consistency5/5

All tools follow the 'memory__<verb>' pattern with clear, single-word verbs (delete, edit, list, read, search, write). Consistent and predictable.

Tool Count5/5

Six tools cover the essential CRUD and browsing operations for a hierarchical memory store. The count is well-scoped without unnecessary complexity.

Completeness4/5

Core CRUD and browsing are covered. Minor gaps like renaming or moving memories exist, but agents can work around by editing content or using multiple steps.

Maintenance

ActivityActive
ResponsivenessNo issues