- 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.