- Reliability 8/20
- Static review is limited to server.json and the README. The manifest is coherent: stdio transport, npx runtime, a single npm package @emilia-protocol/[email protected], and an explicit server.json path. However no tool schemas, server source, dependency lock, or committed CI workflow files are available for inspection; the badges, 35 security claims over 259 evidence files, 10,601+ tests, Tamarin/Alloy/TLA+ results, and 21-suite/335-vector conformance numbers are self-reported and unverifiable here. The default three-tool action surface versus EP_INCLUDE_PROTOCOL_TOOLS (handshake/commit/delegation) and EP_INCLUDE_REGISTRY_TOOLS (36-tool legacy catalog) implies a very different capability surface per configuration, and declared-versus-actual tool behavior cannot be checked. Error semantics (INDETERMINATE requires reconciliation rather than retry) are well described but lack reproducible codes or fixtures. Capped at 12 by static calibration and reduced for missing evidence: 8.
- Security and permissions 9/20
- Positive signals: EP_API_KEY is marked isSecret:true and isRequired:false, so read-only receipt lookup can run without a credential, which supports least privilege and graceful degradation; the core is Apache-2.0 and the README explicitly states that Gate only constrains fully mediated paths, claims no FIPS validation, and does not assert IETF adoption, avoiding overclaiming. Risks: this server sits exactly at the boundary of consequential actions (wire release, repo deletion, production deploy), and enabling EP_INCLUDE_REGISTRY_TOOLS exposes 36 legacy tools whose destructive potential differs sharply from the default surface. Per-tool confirmation policy, audit logging, and where durable consumption state lives are absent from the readable evidence, and there is no guidance on key rotation or key scoping for the environment-injected API key. No malware, credential theft, covert exfiltration, or hardcoded live tokens were found, so no red line is triggered, but confirmation and scoping evidence is incomplete: 9.
- Maintenance 11/20
- There is a clear Apache-2.0 license, semantic version 2.1.2, a public repository and website, a portfolio of IETF Internet-Drafts, and a Discord channel; README references SECURITY.md, THREAT_MODEL.md, GOVERNANCE.md, and CONFORMANCE.md, implying a security-response and governance path. The README also self-discloses unfinished work (leased-edge propagation, portable signed freeze-event evidence, incomplete stack-wide hybrid signatures, no SCITT Transparency Service acceptance, pending externally attested manifest), which is a good maintenance-signal trait. Deductions: no commit history, release cadence, issue-response record, or dependency-update evidence was available to this review; 15 open issues carry no response-time information; and version identity is fragmented across the metadata and docs (0.5.0, 0.6.0, 2.1.2, plus a 16-suite baseline alongside a 21-suite corpus), which complicates version governance. Score 11.
- Documentation 12/20
- Documentation volume is the strongest aspect here: the README is layered, separates Identity/Policy/Authority, lays out the Mandate -> Exact Work -> Verify -> Reserve+Enter -> Reconcile lifecycle, documents the default three-tool front door plus the two optional tool-expansion environment variables, and gives multi-language integration examples (Python langchain-emilia, npm verify), quickstart commands, and an AEB-1 conformance entry point. It commendably publishes negative/boundary claims (not an identity system, not a settlement rail, not a universal policy engine, Internet-Draft is not an RFC or IETF endorsement) and calls out INDETERMINATE as a state to reconcile rather than retry. Deductions: per-tool MCP parameter docs, input/output schemas, error codes, and cost/usage disclosures are missing from the readable evidence; many statistical claims and external references cannot be verified statically; and repeated archiving/staging disclaimers add reader overhead. Score 12.
- Setup experience 9/20
- The install path is reasonably clear: `npx -y @emilia-protocol/mcp-server` adds the server to Claude/Cursor/Cline, stdio avoids port setup, and only EP_API_KEY plus two optional flags are needed, which matches mainstream client conventions; an offline `npx @emilia-protocol/issue demo` provides a pre-flight check without a key. Significant deductions: npx fetches and executes a remote npm package whose contents and version 2.1.2 cannot be validated statically; no per-client config file snippets (e.g., claude_desktop_config.json or .mcp.json) are given; production usability depends on a self-hosted Gate, shared durable consumption state, pinned keys, and wrapping every path to the real provider credential, which contradicts the light 'try it in 30 seconds' impression; and the repository root supplies server.json but no readable server source, dependency manifest, or Node version requirement. Capped at 15 by static calibration and reduced for missing evidence: 9.