engram MCP工具

Install

brew install gentleman-programming/tap/engram

Windows, Linux, and other install methods → docs/INSTALLATION.md

Setup Your Agent

Full per-agent config, Memory Protocol, and compaction survival → docs/AGENT-SETUP.md

What engram setup does — it writes MCP config and plugin files for the chosen agent. After setup, restart your agent and it is ready. No server to start manually.

Do I need to run engram serve or engram mcp myself? For most agents (Claude Code, Gemini CLI, Codex, VS Code, Cursor, Windsurf) — no. Your agent launches engram mcp automatically as a short-lived stdio subprocess whenever it starts a session. You never run it manually. engram serve is only needed when a plugin uses the HTTP API for session tracking: the OpenCode plugin and the Pi extension both talk to engram serve in the background. engram setup opencode and engram setup pi note this; the plugins auto-start the server when possible. If your environment blocks background processes, start it manually in a separate terminal:

> engram serve   # runs on port 7437 by default; keep it running
> 

You do not need engram serve at all for stdio-only agents (Claude Code, Gemini CLI, Codex, VS Code, Cursor, Windsurf).

No Node.js, no Python, no Docker. One binary, one SQLite file.

Setup (4 commands)

```bash git clone https://github.com/Gentleman-Programming/engram.git engram-beta-repo cd engram-beta-repo && git checkout feat/memory-conflict-surfacing-cloud-sync docker compose -f docker-compose.beta.yml up -d go build -o ./engram-beta ./cmd/engram

Quick Start

Use cases

1️⃣ Phase 1 — Conflict detection on save (sanity)

./engram-beta save \
  "Use Clean Architecture" \
  "Layers: entities, use cases, adapters." \
  --type architecture --project beta-test

./engram-beta save \
  "Use Hexagonal Architecture" \
  "Ports and adapters separate domain from infra." \
  --type architecture --project beta-test

✅ Second save returns candidates[] with the first memory's id.

2️⃣ Phase 2 — Cloud sync of relations cross-machine

```bash ./engram-beta cloud enroll beta-test ./engram-beta sync --cloud --project beta-test ./engram-beta cloud status

Isolated env (does NOT touch ~/.engram or your prod cloud)

export ENGRAM_DATA_DIR=/tmp/engram-beta-data export ENGRAM_CLOUD_SERVER=http://127.0.0.1:28080 export ENGRAM_CLOUD_TOKEN=beta-token-CHANGE-ME-please-32chars mkdir -p "$ENGRAM_DATA_DIR" ```

Key Environment Variables

Full environment variable reference → DOCS.md#environment-variables

CLI Reference

Full CLI with all flags → docs/ARCHITECTURE.md#cli-reference

Pi Package

Engram has a first-class Pi package: gentle-engram.

engram setup pi

It gives Pi persistent project memory, compaction recovery, and shared memory with other MCP agents through the same local-or-cloud Engram brain. The package is part of the Gentleman Programming agentic-coding ecosystem alongside Gentle-AI, SDD, skills, and Engram Cloud.

Cloud Integration (Opt-In Replication)

Cloud is optional. Local SQLite stays authoritative; cloud is replication/shared access only.

Recommended first path (local smoke):

docker compose -f docker-compose.cloud.yml up -d
engram cloud config --server http://127.0.0.1:18080
engram cloud enroll smoke-project
engram sync --cloud --project smoke-project

Cloud mode is always project-scoped (--project is required; engram sync --cloud --all is intentionally blocked). ENGRAM_CLOUD_ALLOWED_PROJECTS is required for engram cloud serve in both token-auth and insecure modes. Set it to * to allow all projects (useful for dev/internal deploys) — this bypasses per-project name enforcement while still requiring a non-empty project on each request. Known repairable cloud sync/upsert/canonicalization failures keep the original error visible and recommend the explicit doctor/repair flow below; Engram never auto-applies repair from sync or autosync. For blocked cloud sync, transport_failed, or legacy session directory repair, see Engram Cloud Troubleshooting. If cloud sync stays blocked after doctor/repair, download the rescue helper and run the recommended exported-row repair:

tools/repair-missing-session-directory.sh --apply --interactive --fix-exported <project>
engram sync --cloud --project <project>

--fix-exported repairs local exported sessions[].directory and observations[] required fields that can still break the final push after doctor reports ready. For sequential legacy sync_mutations blockers, use tools/repair-missing-session-directory.sh --apply --interactive --all <project>.

After upgrading engram while an MCP client is already running:

engram setup claude-code

Then restart Claude Code so it reloads the Engram MCP subprocess and refreshed hook/config files. Updating the engram binary on disk does not replace an already-running stdio MCP process.

Upgrade flow for existing local databases (diagnose → repair → bootstrap → status):

engram cloud upgrade doctor --project smoke-project        # read-only readiness check
engram cloud upgrade repair --project smoke-project --dry-run
engram cloud upgrade repair --project smoke-project --apply
engram cloud upgrade bootstrap --project smoke-project     # resumable enroll + push + verify
engram cloud upgrade status --project smoke-project        # stage/class/reason

See DOCS.md — Cloud upgrade flow for the full state machine.

For authenticated mode, upgrade flow, dashboard behavior, reason codes, and full runtime/env details:

• Engram Cloud docs landing
• Engram Cloud quickstart
• DOCS.md — Cloud CLI reference
• DOCS.md — Cloud Autosync

Setup FAQ

When do I need to manually add config to my agent's prompt or settings?

engram setup covers the MCP wiring automatically. Manual config — adding a Memory Protocol snippet to your CLAUDE.md, GEMINI.md, .cursorrules, etc. — is only needed if your agent keeps forgetting to use Engram after long sessions or context compaction. That manual step is called the "nuclear option" in the detailed docs because system prompts survive everything, including compaction. It is a reliability boost for heavy users, not a required first step. See Agent Setup → Surviving Compaction for the snippets.

Can Docker agents (or remote agents) connect to Engram's MCP?

Engram's MCP transport is stdio only — there is no HTTP or network MCP endpoint. engram mcp speaks the MCP protocol over stdin/stdout; it cannot be reached over a TCP port.

If you have agents running in Docker that need to write to Engram on the host, the available paths are:

• HTTP REST API (engram serve): note that engram serve currently binds to 127.0.0.1 only, so it is not reachable from inside a container out of the box — a container cannot reach the host's loopback, and there is no bind-address flag yet. ENGRAM_URL lets the Pi plugin target an engram serve reachable on a routable host/port (e.g. ENGRAM_URL=http://host.docker.internal:7437 pi), but that only works once the server listens on a non-loopback interface, which is not supported today. The HTTP API is not the MCP protocol; Pi uses it for session capture and Pi-native mem_* tools. For Docker right now, prefer the stdio path below.
• Stdio MCP (mount the binary): the cleanest path for a Dockerized agent that needs MCP tools is to mount the engram binary into the container and let the agent launch engram mcp locally via stdio, pointing ENGRAM_DATA_DIR at a volume shared with the host.

Full environment variable reference → DOCS.md#environment-variables

Full guide + troubleshooting

→ docs/BETA_TESTING.md

→ Report feedback: issues with beta-phase-2-3-4 label