← Back to directory
P

Piia Engram

Community
Local-first AI work identity you can see, edit, and override — portable across your MCP coding tools.
Category
Dev Tools #133 of 438
Stars
★ 162 Very popular
Transport
stdio (local process) · SSE
Runtime
Python 3.10+
Credentials
No credential needed
License
AGPL-3.0
Last commit
Tools
58
59FMRS · C

Piia Engram is a local-first AI work identity and memory layer from an individual-led open-source project (AGPL-3.0), not an Anthropic or MCP-official offering. Its positioning is deliberate and clearly differentiated from agent task-memory stores such as Mem0, Zep, and Letta: it stores who you are — identity, preferences, quality standards, lessons, and decisions — rather than what happened in one workflow. Data lives as plaintext JSON/Markdown under ~/.engram/, with zero network calls by default and no cloud account, so you can open, edit, back up, or migrate it yourself. Nineteen core tools load by default, with ENGRAM_TOOLS=all unlocking all 59; writes pass through a tiered governance and staging model where high-risk content needs human approval and strict mode can gate everything. Cross-tool continuity is backed by a verifiable evidence path (a documented Claude Code → Codex continuity proof plus a synthetic MCIC benchmark), and a read-only Preview/Memory Lens shows exactly what a caller would receive. Its boundaries are stated just as honestly: plaintext storage by default, caller identity from environment variables rather than strong authentication, governance as a local policy layer rather than a hardened sandbox, and an explicit warning not to store keys or customer PII. A strong fit for individual developers who juggle multiple MCP coding tools and value local data sovereignty; a poor fit for teams needing shared memory, enterprise support, or a commercial license.

Strongest · Setup experience 14/20 Weakest · Reliability 10/20

Reliability
10/20
Security and permissions
12/20
Maintenance
12/20
Documentation
11/20
Setup experience
14/20
Why each score
Reliability 10/20
Static material shows a plausible startup path: the server is shipped as a PyPI package with a stdio console script (piia-engram-mcp), the manifest pins --transport stdio with an exact version 4.20.0, and the design claims sub-100ms local cold start with zero network calls for identity/knowledge tools, so a clean MCP init and tool-list handshake are credible. However nothing here was executed, and the README contradicts itself on tool surface: counts oscillate between 59, 19+40, 18 and 18+40 (the 'Tier-1 Core (18 tools)' heading lists 19 rows while the body says '19 Tier-1 Core'), and the manifest declares 0 prompts and 0 resources, so declared behaviour may not match runtime. No readable CI workflow content or committed test bodies are included as verifiable execution evidence, and dependency/error-control paths are asserted rather than shown. Per the static calibration ceiling (no execution evidence means reliability <= 12), the contradictions and absence of inspectable test/CI content justify a score of 10.
Security and permissions 12/20
Security evidence is comparatively strong and self-disclosed: data defaults to local ~/.engram/ JSON/Markdown, identity and knowledge tools make zero network calls by default, telemetry is off by default and requires explicit opt-in sending counts only, remote SSE examples use an ENGRAM_AUTH_TOKEN placeholder rather than a real secret, and the default bind is 127.0.0.1 with HTTPS/CORS guidance. Risk-scoping is documented: high-risk writes (credentials, shell commands, MCP config, permission rules) wait for human review by default, exports/imports are owner-gated under ENGRAM_GOVERNANCE=1, and AES-256-GCM field-level encryption is opt-in. Deductions: low/medium writes are auto-absorbed unless ENGRAM_APPROVAL=strict, governance keys off MCP environment variables rather than cryptographic caller identity, the README itself concedes any process with read access to ~/.engram/ can read the data and that restricted_fields is not an ACL or encryption, and playbook auto-extraction/startup sync are implicit side effects enabled by default. These are honest local-policy boundaries, not a hardened sandbox, and no red line (malware, covert exfiltration, real secrets in examples, unconfirmed destructive defaults) is evidenced.
Maintenance 12/20
Activity signals are positive: an explicit version (4.20.0) with a stated verification date, an AGPL-3.0 license in the repo (AGPL-3.0-or-later in the manifest — a minor inconsistency but not absence), referenced CI and guard-strategic-files GitHub Actions badges, a CHANGELOG, a CONTRIBUTING.md, a named creator/owner, plus described release gates, public-fact sync checks and versioned tool contracts, with maintainer identity appearing genuine rather than fabricated. Deductions: static files cannot confirm the workflows behind the CI badges, and there is no first-party evidence of commit cadence, release history, dependency-update policy, or a security-response channel (SECURITY.md is cited but not provided); issue response cannot be judged with 0 open issues; 160 stars is a discovery signal only and adds nothing; and maintenance depends on a single named maintainer, a concentration risk.
Documentation 11/20
Documentation is extensive and layered: install wizard, quickstart, per-client config snippets (Claude Code, Cursor, Codex, Claude Desktop, plus generic MCP-over-stdio), a 59-tool responsibility table, data layout, CLI command reference, trust model, privacy, competitor comparison, an explicit Limitations table, and multiple docs/ references; install and client examples are concrete enough to follow, and limitations (concurrent writes, caller identity blocked by MCP spec, field-level-only encryption, restricted_fields not being an ACL) are voluntarily disclosed. Deductions: the same self-contradiction on tool counts (18 vs 19 core, 59 total) appears in multiple places and conflicts with the manifest's declared capability counts; several cited docs (trust.md, comparison.md, context-governance.md, tests, scripts, SECURITY.md, public-facts.json) are outside the supplied material and cannot be verified; unverified compatibility labels ('Expected to work', 'Usable') sit beside a formal evidence-level table, inviting over-read; and cost/dependency/error-troubleshooting guidance lacks corroborating first-party evidence.
Setup experience 14/20
The install path is clear and client-friendly: a single pip install piia-engram && engram setup, plus a zero-install uvx --from piia-engram==4.20.0 piia-engram-mcp path; the manifest pins the exact package version and runtime arguments, sharply reducing environment drift, and the README supplies complete mcpServers JSON for Claude Code, Cursor, Codex, Claude Desktop and generic stdio clients, including a python -m piia_engram.mcp_server fallback. Troubleshooting is concrete (engram doctor, doctor --fix, restart the client), and the wizard backs up external configs and requires confirmation before writing. Deductions: no executable or committable evidence that any of these installs actually succeed, Python 3.10+ plus optional extras (remote, secure, vector, reader) add complexity, Windows needs PYTHONIOENCODING guidance, some domestic IDEs require manual pasting, and per-platform differences are not enumerated. Per the static ceiling (no verifiable execution evidence means setup <= 15), 14 is appropriate.

Static review · not runListed 2026-09-10

Read the FMRS scoring method →

Fit and risk

What it can accessReads local filesWrites / deletes local filesUses the network

Best for

  • Developers who use several MCP-compatible AI coding tools and are tired of re-explaining themselves.
  • Users who want memory and identity data to stay on their own machine, inspectable and editable.
  • Individuals or small teams long-term-accumulating quality standards, architecture decisions, and technical lessons.
  • Vibe-coding workflows that need continuity across sessions, tools, and projects.
  • Users who accept human review gates in exchange for local data sovereignty.

Not for

  • Multi-person collaboration, team-shared memory, or centrally managed server deployments (this is a personal identity layer).
  • Anyone needing vendor SLAs, enterprise support, or a commercial license (AGPL-3.0, no separate commercial license).
  • Storing passwords, API keys, or customer PII — the project explicitly advises against it.
  • Users whose primary need is agent task memory/session history and who have already chosen Mem0/Zep/Letta-style tools.
  • Scenarios demanding hardened access control over plaintext local files: restricted_fields and the governance layer are not encryption or a true ACL.

Required permissions

  • Read and write JSON/Markdown files under the local Engram data folder (default ~/.engram/).
  • Write AI-client MCP config and instruction files during engram setup, only after your confirmation (backed up first; decline leaves them untouched).
  • Write a local-only audit log at ~/.engram/audit.log, enabled by default (opt out with ENGRAM_AUDIT=0).
  • Optional: read_web_content fetches a URL you provide, via a local sidecar or the built-in reader.
  • Optional: ENGRAM_TOOLS=all exposes all 59 tools to the model, including owner/admin export, import, and trust-management interfaces.
  • Optional: remote SSE mode requires ENGRAM_AUTH_TOKEN and should sit behind a TLS reverse proxy.
  • Optional: telemetry is off by default; enabling remote telemetry or feedback is separate explicit opt-in and sends counts only.

Risks and side effects

  • Data is plaintext JSON/Markdown by default, so any process that can read ~/.engram/ can read your data; field-level encryption is optional, not the default.
  • The project explicitly warns against storing passwords, API keys, or client PII in Engram.
  • restricted_fields only reduces what is emitted in cold-start context — it is not encryption or a real ACL.
  • Caller identity comes from MCP environment variables rather than cryptographic authentication, so governance is a practical local policy boundary, not a hardened sandbox; the MCP spec does not pass tool identity.
  • Export outputs (export_engram, get_identity_card, export_knowledge_report) contain full or broad content and should be treated as sensitive files.
  • import_engram mutates the local store: always preview with dry_run=True first; applying requires explicit --apply --yes.
  • Concurrent writes rely on a file lock plus atomic replace; network-filesystem edge cases are not guaranteed.
  • Playbook auto-extraction redacts sensitive info before staging (keys, tokens, absolute paths, emails), but drafts remain untrusted until you confirm them.
  • Remote deployment without proper HTTPS and token handling can expose identity data.

Setup

Before you start

Runtime:Python 3.10+

ENGRAM_SECRET optionalsecret Local passphrase for optional field-level AES-256-GCM encryption, chosen by the user; requires pip install piia-engram[secure].
ENGRAM_AUTH_TOKEN optionalsecret Bearer token for remote SSE mode, generated locally via secrets.token_urlsafe(32).
Other optional settings (10)
ENGRAM_MCP_STARTUP_SYNC optional Controls local startup sync for the MCP server; set to off to skip it, background is the default.
ENGRAM_TOOLS optional Controls the exposed tool surface; default core (19 tools), set to all for the full 59-tool advanced surface.
PYTHONIOENCODING optional Forces UTF-8 stdio frames on Windows-style consoles; set to utf-8.
ENGRAM_APPROVAL optional Write-approval policy; set to strict to gate every write behind human review.
ENGRAM_SEARCH optional Search mode; set to hybrid to enable FTS5 + vector hybrid retrieval (requires pip install "piia-engram[vector]").
ENGRAM_GOVERNANCE optional Enables per-caller trust-level governance; set to 1 to turn on.
ENGRAM_CLIENT_TYPE optional Declares caller identity when governance is on, e.g. claude_code.
ENGRAM_AUDIT optional Local audit log toggle; set to 0 to disable writing ~/.engram/audit.log.
ENGRAM_EPHEMERAL optional Set to 1 in container/ephemeral clients to skip startup sync and migration work.
ENGRAM_CORS_ORIGINS optional Restricts cross-origin access in remote deployments, e.g. https://your-domain.com.

Option 1 (pip): run pip install piia-engram && engram setup. The wizard detects your Python environment, lets you choose the Engram data folder (~/.engram, another drive, or a custom path), detects your AI tools and lists the exact config files it will touch, and writes the MCP connection only after a one-keystroke confirm (every write is backed up first; decline and nothing changes). It then walks you through seed knowledge (role, tech stack, language), can smart-import rules from existing CLAUDE.md / .cursorrules files, and previews your AI identity card.

Option 2 (uvx, no prior install): use uvx --from piia-engram piia-engram-mcp in your client config.

Client config example (Claude Desktop / generic MCP over stdio):

{
  "mcpServers": {
    "piia-engram": {
      "command": "python",
      "args": ["-m", "piia_engram.mcp_server"]
    }
  }
}

Cursor uses ~/.cursor/mcp.json, Codex uses ~/.codex/mcp.json, Claude Desktop uses claude_desktop_config.json. Claude Code also supports claude mcp add piia-engram -- piia-engram-mcp.

For non-interactive or CI runs, engram setup --apply-external-config skips the confirmation prompt (backups are still taken). Restart your AI tool afterwards and run engram doctor to verify connectivity.

Optional environment variables: ENGRAM_TOOLS=core|all (default core exposes the 19 core tools; all unlocks the full 59), ENGRAM_MCP_STARTUP_SYNC=off|background|eager (default off; background is for local cross-tool sync), PYTHONIOENCODING=utf-8 (Windows-style consoles).

Remote deployment: pip install piia-engram[remote], generate a token, then start ENGRAM_AUTH_TOKEN=... python -m piia_engram.mcp_server --transport sse --host 0.0.0.0 --port 8767. Clients connect with a url plus an Authorization: Bearer header; always put it behind TLS in production.

.mcp.json
{
  "mcpServers": {
    "piia-engram": {
      "command": "python",
      "args": ["-m", "piia_engram.mcp_server"]
    }
  }
}

Shown for Claude Code. Other clients may use a different file or key (VS Code uses "servers") — the configurator below converts it.

.vscode/mcp.json
{
  "servers": {
    "piia-engram": {
      "command": "python",
      "args": [
        "-m",
        "piia_engram.mcp_server"
      ]
    }
  }
}

Goes in your project's .vscode/mcp.json (VS Code uses a "servers" key).

Terminal
claude mcp add piia-engram -- python -m piia_engram.mcp_server

Run it in a terminal; replace any <…> placeholders with your own values first.

Check that it works

Run engram doctor to confirm your tools are detected and configured as healthy; the piia-engram tools (e.g. get_user_context) should appear in your client's tool list, and calling one should return your identity and knowledge context.

Troubleshooting

  1. After upgrading, an AI tool shows "MCP server disconnected": run `engram doctor --fix`, then restart the tool (it scans known MCP config files, removes outdated entries, and repairs paths).
  2. Unsure whether setup worked: run `engram doctor` for detected tools, store health, and the active capability mode; `engram capabilities --json` gives machine-readable capability codes and contract versions.
  3. Want to see exactly what AI would receive: run `engram preview --as automation` (or --html). It is read-only and sends nothing.
  4. Want a smaller tool surface: set ENGRAM_TOOLS=core (or compose capability groups), then re-run `engram doctor` to confirm the reported core surface.
  5. Slow startup or latency-sensitive test arms: set ENGRAM_MCP_STARTUP_SYNC=off to skip startup sync; ENGRAM_EPHEMERAL=1 also skips startup sync and migration in container/ephemeral clients.
  6. Encoding errors on Windows-style consoles: set PYTHONIOENCODING=utf-8; for garbled/mojibake text, dry-run `engram repair-encoding` then `--apply` (with backup).
  7. Before an upgrade, see what to copy: `engram backup-plan` prints a metadata-only list covering only the Engram directory and never touches project folders.
  8. Check cross-tool handoff readiness: `engram continuity` (metadata only; prints no memory bodies, session IDs, or local paths).
  9. Inspect privacy and telemetry: `engram privacy`, `engram telemetry preview`, `engram telemetry off`, `engram telemetry remote off`.

Things to try

Once connected, you can ask your AI assistant things like:

  • Remember this lesson: always separate auth middleware from business logic when refactoring
  • Search my knowledge for past lessons about pytest coverage standards
  • Wrap up this session and save the key decisions we made
  • Show me a health report of my knowledge base and any stale items

Tools 58

get_user_context read-only
Startup — load identity and knowledge at session start (supports token_budget for context-size control).
wrap_up_session writes
Session end — save insights and sync at session end.
memory_store writes
Unified write endpoint: routes to add_lesson / add_decision / add_playbook by kind.
add_lesson writes
Store a reusable lesson learned.
add_decision writes
Record a key decision with its reasoning.
add_playbook writes
Record an operational playbook (a multi-step procedure with trigger keywords).
search_knowledge read-only
Retrieval — search lessons, decisions, and playbooks (supports filters_json for domain/tier/date filtering).
get_relevant_knowledge read-only
Find knowledge relevant to the current project.
Show 50 more tools
get_recall read-only
Return one structured recall payload: identity + recent activity + relevant knowledge.
get_knowledge_history read-only
Read one item's revision history (superseded snapshots; exact by-version lookup).
get_identity_card writes
Owner-gated export: write and return a Markdown identity card for non-MCP tools.
update_identity writes
Update profile, preferences, or quality standards.
get_project_context read-only
Read a saved project snapshot.
save_project_snapshot writes
Persist project state for future sessions.
get_recent_context read-only
Recover lost session context after a restart.
get_daily_log read-only
Read a human-friendly project timeline for a day.
get_resume_brief read-only
Build a cross-session, cross-tool resume brief.
doctor read-only
Run memory-system self-diagnosis.
register_tool writes
Optional local integration (governed write): register a local tool, runtime, or CLI to the environment map.
find_tool read-only
Optional local integration: look up a registered local tool by name.
list_tools read-only
Optional local integration: list registered local tools (optionally filtered by category).
save_agent_context writes
Save an AI session checkpoint (also runs automatically).
list_agent_sessions read-only
Browse saved session records across tools.
refresh_quick_context writes
Refresh the local quick_context.md snapshot for offline and cross-tool use.
get_identity_facets read-only
Read identity facets via facet: profile, preferences, trust_boundaries, work_style, quality_standards, domains, or all.
user_portrait read-only
action: get / save / compare the AI-maintained user portrait.
preview_context_governance read-only
Advanced owner-gated preview: build safe-context, freshness/conflict, replay, or evidence proposals without applying changes.
get_playbooks read-only
Playbook reads via mode: list, get (full content), recent, management (including archived/deleted metadata).
manage_playbook writes
Playbook lifecycle via action: update, archive, delete, restore (mutations stay confirm-gated).
playbook_execution read-only
Guided execution via action: prepare a step plan, update_step, status rollup (passive reference; no auto-execution).
get_lessons read-only
List reusable lessons learned.
get_decisions read-only
List key decisions; thread_seed_id / history_question reconstruct decision threads and revision history.
get_knowledge_inheritance read-only
Build a cross-project knowledge starter pack.
list_projects read-only
List saved project snapshots.
extract_session_insights writes
Extract and store lessons and decisions from session text.
ingest_notes writes
Parse free-form notes into structured knowledge.
update_knowledge writes
Update a lesson or decision by ID.
archive_knowledge writes
Archive a lesson or decision by ID.
confirm_knowledge writes
Owner-only confirmation stamp via human, test, or anchor provenance.
onboard_repo writes
Owner-only repo scan: create staging repo-fact candidates from anchors.
onboard_accept writes
Owner-only accept: validate a candidate anchor and promote it to verified.
check_anchors read-only
Owner-only revalidation for existing anchor-backed facts.
merge_knowledge writes
Merge a duplicate into the primary item.
manage_relation writes
action: link / unlink — manage typed relations between knowledge items (decision threads).
explore_knowledge read-only
Knowledge-graph exploration via mode: related, similar, merge_candidates.
get_knowledge_overview read-only
Knowledge digest, health report, and stale checks.
get_stale_knowledge read-only
List items that need review.
review_staging writes
Staging review hub via action: list pending, batch decisions, review_item, apply_text review results.
export_knowledge_report writes
Owner-gated export: write a readable Markdown knowledge report.
request_outline_review writes
Owner-gated export: generate an interactive local HTML review page.
export_engram writes
Owner-gated export: write a full backup (format="openclaw" for OpenClaw-compatible files).
import_engram writes
Owner/admin import: use dry_run=True first for a metadata-only merge/conflict preview (format="openclaw" supported).
read_web_content read-only
Fetch a user-provided URL: prefers a local sidecar if running, otherwise uses the self-contained built-in reader (pip install "piia-engram[reader]").
get_audit_log read-only
Get recent audit log entries.
start_project writes
Start a project with inherited knowledge.
get_permission_profile read-only
View all callers' trust levels and access boundaries.
manage_caller_trust writes
Owner/admin action: grant / revoke a caller's trust level.
export_feedback_report writes
Maintainer feedback: generate an anonymous aggregate feedback report.

Use cases

Share one set of identity, preferences, and lessons across multiple MCP coding tools such as Claude Code, Codex, and Cursor.
Make every new AI session start from the same approved context instead of from zero.
Keep living architecture decision records: what you chose, what you ruled out, and why.
Describe a new project in plain text and get a curated starter pack of relevant lessons and decisions from prior work via get_knowledge_inheritance.
Paste a session summary into extract_session_insights so knowledge accumulates passively without manual note-taking.
Export a ready-to-paste Markdown identity card with get_identity_card for tools that do not support MCP (ChatGPT, Gemini, Kimi).
Auto-draft structured playbooks from repeated multi-step workflows (release to PyPI, deploy, publish) and reuse them later.
Register installed runtimes and CLIs once (register_tool / find_tool) instead of re-discovering the environment every session.
Audit knowledge health, find near-duplicates, and link related items with get_knowledge_overview, explore_knowledge, and manage_relation.
Run the server remotely in SSE mode with a Bearer token for access from anywhere.

Supported clients

Claude Code
Codex
Cursor
Claude DesktopPartial support
Hermes
OpenClawPartial support
WindsurfPartial support
GitHub CopilotPartial support
ClinePartial support
Roo CodePartial support
Amazon QPartial support
AugmentPartial support
ZedPartial support
TraePartial support
Tencent CodeBuddyPartial support
ChatGPT / Gemini / KimiPartial support

Listed from the project's documentation, not tested by this site.

Overview

Piia Engram is a local-first AI work identity and memory layer for MCP-compatible coding tools such as Claude Code, Codex, Cursor, Windsurf, and Claude Desktop. You tell it once who you are, how you work, and what "good" means; multiple AI tools can then start from the same approved context — identity, preferences, quality standards, code-review bar, lessons learned, key decisions, and project snapshots — stored as plain JSON and Markdown under ~/.engram/ on your machine. There is no cloud account and no hidden memory you cannot inspect.

It deliberately occupies a different layer from agent task-memory databases like Mem0, Zep, or Letta: those store what happened during a workflow, while Piia Engram stores who is behind every task. It ships 59 MCP tools, but only 19 Tier-1 core tools are loaded by default to keep context clean; setting ENGRAM_TOOLS=all unlocks the full surface (knowledge management, governance, import/export, admin).

Writes follow a governance model: AI writes locally, high-risk items (credentials, shell commands, MCP config, permission rules) wait in staging for your review, and low/medium writes are auto-absorbed but fully auditable and reversible. ENGRAM_APPROVAL=strict gates every write. Other capabilities include cross-project knowledge inheritance, session-insight extraction, playbook auto-extraction (drafts only — you confirm before a playbook becomes trusted), a local tools registry, knowledge health and near-duplicate discovery, optional hybrid retrieval (FTS5 plus a semantic vector layer, off by default), optional field-level AES-256-GCM encryption, and a local audit log.

By default the identity and knowledge tools make zero network calls (except the optional read_web_content); telemetry is off by default, and remote telemetry or feedback requires separate explicit opt-in and sends counts only. Licensed AGPL-3.0, created by @Patdolitse with Claude Code and Codex as AI assistants — a community open-source project, not an Anthropic or MCP-official offering.

Similar servers

Context7 80 · B

Upstash's official server providing up-to-date third-party library docs for AI coding assistants

★ 63.3k · Tools 2 Compare with this →

Source revision aafb8801a141 Data synced 2026-10-19 Read the FMRS scoring method