Public assessment

emiliaprotocol/emilia-protocol (@emilia-protocol/mcp-server)

emilia-protocol-mcp-server · v1.0.0 · scanned Aug 3, 2026

What changed in the harness

Selection accuracy 100→100, token cost up 4%, unconfirmed writes 6%→6%.

Category breakdown

Where the score comes from.

Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.

01Safety

1.9 / 30

1.9 out of 30

02Legibility

27.2 / 30

27.2 out of 30

03Economics

18.7 / 20

18.7 out of 20

04Discoverability

14.9 / 20

14.9 out of 20

Highest-impact fix

Estimated gain +28 points

Add explicit identity and permission preflight tools

Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.

Description evidence

Defects and rewrites.

5 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.

Tool	Defect types	Suggested rewrite
`ep_list_policies`	no_return_description	List all available trust policies with their requirements and policy families, letting you discover which policy to evaluate against. Returns the full set of policies, each with its requirements and family, so you can pick the right one for ep_install_preflight or other evaluations.
`ep_issue_commit`	params_unexplained	Issue a signed EP Commit before a high-stakes action, binding the agent to a specific action type, entity, and policy before execution. Returns a commit_id, decision (allow/deny/review), expiry, scope, and appeal path. Pass action_type (install, connect, delegate, transact), the entity_id requesting the commit, an optional principal_id authorizing it, and an optional counterparty_entity_id identifying the other party on the opposite side of the action (e.g. the merchant, vendor, or recipient). delegation_id, scope, max_value_usd, context, and policy further constrain what the commit authorizes.
`ep_bind_receipt_to_commit`	no_return_description	Bind a post-action receipt to a commit, completing the commit-execute-receipt cycle by linking the behavioral outcome back to the signed authorization token. Returns the updated commit state (e.g. fulfilled) and confirmation that the receipt is now associated with the commit, so the authorization-to-outcome link is verifiable.
`ep_initiate_handshake`	no_return_description	Initiate an EP Handshake — a structured identity exchange between parties that coordinates mutual presentation of identity proofs before a trust decision. Requires at least 2 parties and a governing trust policy. Returns a handshake_id and the initial handshake state, to be used in subsequent ep_add_presentation and ep_verify_handshake calls.
`ep_revoke_handshake`	no_return_description	Revoke an active handshake. Only parties to the handshake may revoke it; revocation is terminal and the handshake cannot be reopened or verified afterward. Returns the terminal revoked state, confirming the handshake is permanently closed.

Selection evidence

Confusable tool pairs.

7 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.

Tool A	Tool B	Confidence	Why they collide
`ep_verify_handshake`	`ep_get_handshake`	medium	Both are read-only lookups on the same artifact sharing state/presentation vocabulary; a task like 'check the handshake result' or 'see where the handshake stands' could lead the agent to get_handshake (full state) instead of verify_handshake (policy decision) since both return outcome-like info.
`ep_verify_commit`	`ep_verify_handshake`	medium	Both are read-only verify calls sharing the 'verify' verb; a task like 'confirm the pending authorization is still valid' is ambiguous because the token could be a commit or a handshake, and the descriptions of both emphasize checking signature/validity.
`ep_verify_delegation`	`ep_verify_handshake`	medium	Both verify a form of authorization/identity proof sharing 'verify' and 'ep'; a task like 'make sure the agent is actually authorized to act' is ambiguous between verifying a delegation record and evaluating a handshake exchange.
`ep_revoke_commit`	`ep_revoke_handshake`	medium	Both terminally cancel a pending authorization artifact with identical 'revoke' semantics; a task like 'revoke the pending approval / call off the pending action' is ambiguous about whether the target is a pre-action commit or a handshake.
`ep_guard_action`	`ep_create_delegation`	medium	Both authorize agent action but at different scopes; a task like 'authorize the agent to carry out this payment' could select guard_action (submit the specific action for approval) or create_delegation (grant standing authority), and both descriptions involve authorization and record creation.
`ep_create_delegation`	`ep_verify_delegation`	low	Shared artifact name 'delegation'; most tasks clearly specify create vs check, but a terse task like 'handle the delegation for agent X' is ambiguous about whether to write or verify the record.
`ep_issue_commit`	`ep_verify_commit`	low	Shared 'commit' artifact; a task like 'make sure we have a valid commit for this action' could be read as issuing a new commit or verifying an existing one, though the verbs usually disambiguate.

Compare the field

One score is useful.
The evidence makes it actionable.

Back to the leaderboard