← Back to directory
E

Emilia Protocol MCP Server

Official
Exact-action approval and verifiable signed receipts for consequential agent actions.
Category
Other #158 of 230
Stars
★ 611 Very popular
Transport
stdio (local process)
Runtime
Node.js
Credentials
Optional API key
License
Apache-2.0
Last commit
49FMRS · D

An upstream-maintained MCP server for the Emilia Protocol authority control plane: it requests, tracks, and verifies signed receipts for exact agent actions at protected executor boundaries. It suits security teams that need finite agent mandates and portable evidence. It is not an identity system, policy engine, settlement rail, or certifier, and its preventive property depends on complete mediation of the protected path. The default tool surface is small, with broader tool sets behind explicit environment switches.

Strongest · Documentation 12/20 Weakest · Reliability 8/20

Reliability
8/20
Security and permissions
9/20
Maintenance
11/20
Documentation
12/20
Setup experience
9/20
Why each score
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.

Static review · not runListed 2026-09-10

Read the FMRS scoring method →

Fit and risk

What it can accessRuns commands or codeUses the networkChanges third-party account data

Best for

  • Teams building autonomous agents on MCP that need an authority control plane
  • Security and platform engineering teams that need exact-action approval and verifiable evidence
  • Enterprise deployments that bind human or institutional authorization to one exact executable action

Not for

  • Projects expecting a replacement for OAuth/OIDC, workload identity, or policy engines
  • Users expecting the server itself to be an auditor, accredited certifier, or settlement rail
  • Deployments that do not place Gate on the credential-owning path yet expect preventive control

Required permissions

  • EP_API_KEY is the key needed for write and live action-guard operations (optional; public receipt lookup may work without it)
  • The server runs as a local stdio process and can read the environment variables configured for it
  • Enabling EP_INCLUDE_REGISTRY_TOOLS exposes additional registry and reputation tool interfaces

Risks and side effects

  • Preventive control holds only under complete mediation; paths that bypass the enforcement point are unconstrained
  • Without EP_API_KEY, write operations and live action guarding may be unavailable
  • Admission is not execution and execution is not effect; unknown results must be reconciled, not blindly retried
  • Environment switches that broaden the advertised tool set widen the exposed surface
  • The referenced IETF documents are individual Internet-Drafts, not RFCs or IETF endorsement

Setup

Before you start

Runtime:Node.js

EP_API_KEY optionalsecret API key for live action-guard, signoff, and write operations; public receipt lookup may work without it. Optional secret.
Other optional settings (2)
EP_INCLUDE_PROTOCOL_TOOLS optional Set to true to advertise handshake, commit, and delegation tools in addition to the default three-tool action front door.
EP_INCLUDE_REGISTRY_TOOLS optional Set to true to advertise the complete 36-tool legacy registry and reputation catalog.
  1. Launch the server from your MCP client with npx: npx -y @emilia-protocol/mcp-server.
  2. For live action-guard, signoff, and write operations, set EP_API_KEY (secret, optional; public receipt lookup may work without it).
  3. To advertise handshake, commit, and delegation tools alongside the default three-tool action front door, set EP_INCLUDE_PROTOCOL_TOOLS=true.
  4. To advertise the complete 36-tool legacy registry and reputation catalog, set EP_INCLUDE_REGISTRY_TOOLS=true.
  5. Restart the client and confirm the server is connected.
claude_desktop_config.json
{
  "mcpServers": {
    "emilia-protocol": {
      "command": "npx",
      "args": [
        "-y",
        "@emilia-protocol/mcp-server"
      ],
      "env": {
        "EP_API_KEY": ""
      }
    }
  }
}

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

.vscode/mcp.json
{
  "servers": {
    "emilia-protocol": {
      "command": "npx",
      "args": [
        "-y",
        "@emilia-protocol/mcp-server"
      ],
      "env": {
        "EP_API_KEY": ""
      }
    }
  }
}

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

Terminal
claude mcp add emilia-protocol -e EP_API_KEY= -- npx -y @emilia-protocol/mcp-server

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

Check that it works

After adding the server to your MCP client, the Emilia Protocol default three-tool action front door (request, track, and verify signed receipts) should appear in the tool list. You can also run `npx -y @emilia-protocol/mcp-server` to confirm it starts, or `npx @emilia-protocol/issue demo` to issue an offline receipt without an API key.

Troubleshooting

  1. Confirm npx can fetch @emilia-protocol/mcp-server and that the npm registry is reachable
  2. If write operations fail, check that EP_API_KEY is set and valid
  3. If handshake, commit, and delegation tools are missing, check that EP_INCLUDE_PROTOCOL_TOOLS is set to true
  4. If registry and reputation tools are missing, check that EP_INCLUDE_REGISTRY_TOOLS is set to true
  5. Restart the MCP client and confirm the stdio process starts without errors

Things to try

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

  • Issue a demo authorization receipt offline for testing.
  • Verify this signed receipt and tell me whether the evidence checks out.
  • Request exact-action approval for this consequential agent action and track it until it is signed.

Use cases

Bind consequential agent actions such as payment release, repository deletion, or production deploy to exact-action authorization receipts
Request, track, and verify signed receipts at a protected executor boundary
Define finite operating mandates for autonomous agents so they cannot quietly widen their authority
Preserve portable evidence for audit and assurance workflows

Supported clients

Claude Desktop

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

Overview

The Emilia Protocol MCP server provides exact-action approval for consequential agent actions. It runs over stdio and is launched with npx from the npm package @emilia-protocol/mcp-server. Per the manifest, it lets clients request, track, and verify signed receipts, and it acts as the MCP-facing front door to the Emilia Gate authority control plane, which enforces finite customer-owned mandates at protected executor boundaries. It advertises a default three-tool action front door, with optional environment switches for handshake, commit, and delegation tools and for the legacy 36-tool registry and reputation catalog. The server is maintained by the upstream Emilia Protocol project (official). It is authorization and evidence infrastructure, not an identity system, wallet, reputation score, settlement rail, or universal policy engine, and it does not require that a human approve every action: authority can come from a bounded mandate, a bounded capability, a quorum, or a relying-party composition of native evidence. Preventive control holds only where the deployment completely mediates the protected path; it constrains no path that bypasses the enforcement point.

Similar servers

BioMCP 75 · B

One binary. One grammar. Evidence from the biomedical sources you already trust.

★ 659 · Tools 11 Compare with this →

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