emilia-mcp-server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| prompts | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ep_guard_actionA | Request authorization before an irreversible action: payments, wire transfers, fund releases, deletions, record or account changes, or sending messages with real-world effect. Submits the exact action for policy evaluation and human authorization. This MCP tool does not itself sit at the executor choke point: even after approval, the executor MUST match the returned action_hash and atomically consume the receipt before effect. If BLOCKED, poll ep_check_signoff with the receipt_id. |
| ep_check_signoffA | Poll a pending authorization after ep_guard_action returns BLOCKED. Pass the receipt_id. Returns PENDING, APPROVED_PENDING_CONSUME, CONSUMED, or DENIED. Approval alone is not permission to execute: the executor must match action_hash and atomically consume the receipt at its own choke point. |
| ep_verify_receiptA | Ask the configured EMILIA service to verify a stored trust receipt and report its hash and anchor status. Read-only, but not an offline verifier: the result is the service response for the supplied receipt_id. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| trust_decision | Get a structured prompt for making a trust-based routing or payment decision about an entity. |
| receipt_quality_check | Get a prompt for evaluating the quality and accuracy of a receipt before submission. |
| install_decision | Get a structured prompt for deciding whether to install a software package or plugin. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Entity Trust Profile | Full trust profile for any entity by ID or slug. Equivalent to ep_trust_profile tool but as a resource. |
| Entity Trust Score | Current trust confidence and score breakdown for an entity. |
| Receipt | Full receipt data including hash, provenance, and verification status. |
| Delegation Record | Delegation details: principal, agent, scope, expiry, and status. |
TDQS
Scored across 3 tools
Each tool addresses a distinct phase of the authorization lifecycle: requesting guard approval, polling signoff status, and verifying a stored trust receipt. There is no meaningful overlap because the inputs and outputs are clearly separated.
All tools share the ep_ prefix and follow a consistent verb_noun pattern: guard_action, check_signoff, verify_receipt. The naming style is uniform and predictable.
Three tools is at the lower end of the ideal range but perfectly scoped for this narrow authorization and verification domain. Each tool has a distinct responsibility and none feel redundant or missing.
The tool surface covers the full declared workflow: request authorization, poll for approval, and verify the trust receipt. Receipt consumption is intentionally outside the MCP server's choke point, so its absence is not a functional gap.