emilia-mcp-server

Official

by emiliaprotocol

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.7
Disambiguation5/5
Each tool targets a distinct operation within the EP protocol, such as handshake management, commit lifecycle, delegation, or verification. Descriptions clearly differentiate between initiating, verifying, revoking, and getting states, so an agent can easily select the correct tool.
Naming Consistency5/5
All tools follow the consistent pattern 'ep_verb_noun' with lowercase and underscores. Verbs like create, get, verify, revoke, initiate, etc., are paired with specific nouns like handshake, commit, delegation, receipt. No mixing of conventions.
Tool Count4/5
With 17 tools, the set is moderately large but well-scoped to cover a comprehensive trust protocol. Each tool serves a necessary function in the workflow, though a few could potentially be merged (e.g., get and verify commit are distinct but similar).
Completeness4/5
The tool set covers the core lifecycle of handshakes, commits, delegations, receipts, and guard actions. Missing are tools for policy management (create/update/delete) and user/agent registration, but these may be out of scope. The surface is sufficient for the stated domain.
Average 4.3/5 across 17 of 17 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 1896 commits in the last 12 weeks
- Last stable release on March 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (mutation) and destructiveHint=false. Description adds that the handshake coordinates mutual presentation of identity proofs before a trust decision, but does not detail side effects, return values, or state changes. With annotations present, the additional behavioral context is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key purpose and constraints. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description should hint at what the handshake returns or how it behaves. It mentions coordination before a trust decision but lacks details on output (e.g., handshake ID, next steps). Given five parameters and nested objects, it is somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. Description adds little beyond re-stating the party requirement (min 2). It does not elaborate on mode options or the binding/interaction_id fields beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it initiates an EP Handshake, a structured identity exchange. It distinguishes from siblings like ep_verify_handshake by focusing on initiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies that at least 2 parties and a governing trust policy are required, giving basic context. However, it does not explicitly mention when to use this tool over alternatives (e.g., ep_verify_handshake) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readonly and non-destructive behavior. The description adds context about the lifecycle cycle and linking to authorization token, but does not disclose specifics about side effects or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences with no wasted words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description provides adequate context about its role in the lifecycle, though return value or error conditions are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with accurate parameter descriptions; the description adds minimal extra value beyond restating the parameter contexts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Bind' and identifies the resource 'receipt to a commit', clearly distinguishing it from sibling tools like ep_issue_commit or ep_verify_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as part of a commit-execute-receipt cycle but provides no explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds behavioral context: the tool creates a binding commitment without destruction. It also discloses return fields (commit_id, decision, expiry, scope, appeal path).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences covering purpose, return values, and binding behavior. No extraneous information, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 params, nested objects, no output schema), the description adequately covers the purpose and return format. It could mention the required parameters explicitly but schema already covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 9 parameters have descriptions in the schema (100% coverage), so baseline is 3. The description does not add extra meaning or usage tips beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Issue' and the resource 'signed EP Commit' with context ('before a high-stakes action'). It differentiates from sibling tools like ep_get_commit_status, ep_revoke_commit, etc., by emphasizing it is a pre-action binding tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before high-stakes actions but does not explicitly indicate when not to use this tool or mention alternatives among the extensive sibling list (e.g., ep_guard_action, ep_install_preflight).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, and the description adds 'WRITE: persists to the EP ledger', which aligns and provides additional behavioral context (persistence, ledger). No contradictions, and the description adds value beyond annotations by mentioning authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with two sentences, but the first sentence is somewhat long and includes multiple pieces of information. It is front-loaded with the verb and resource, but could be slightly more structured. Still, it is efficient without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description adequately explains the return value ('Returns a delegation_id that later actions reference'). It also covers key aspects like scope, expiry, constraints, and the fact that it requires auth. For a tool with 6 parameters and nested objects, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description. The tool description adds overall context but does not significantly elaborate on individual parameters beyond what the schema provides. The baseline of 3 is appropriate as the description does not add extra semantics for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a delegation record' and explains the purpose of persisting authorization. It distinguishes from siblings by mentioning that the returned delegation_id is used by ep_verify_delegation, providing a specific verb-resource pair and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when a principal grants an agent standing authority for a bounded set of actions' and mentions 'Requires auth.' While it doesn't specify when not to use, it provides clear context for appropriate use relative to the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and destructiveHint. Description adds concrete return values (statuses, action hash, expiry) and tells agent to poll, adding useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and read-only nature, no waste. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only status tool with one parameter, description is complete. Lists return fields even without output schema. No missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with description for commit_id. Description does not add new parameter meaning beyond what schema provides (id format). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specifies exactly what the tool does (get commit status by ID), explicitly states read-only, and distinguishes from siblings like ep_verify_commit and ep_revoke_commit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear use case stated: 'poll this to learn whether a commit may still be consumed.' Does not explicitly mention when not to use, but context implies it's for status polling only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety. It adds value by detailing what the state includes (parties, presentations, binding, result), which is useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the purpose and usage guidance. Every sentence is essential and adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one simple parameter, good annotations, and no output schema, the description is sufficient. It explains what the tool returns and when to use it. The brief mention of components compensates for the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter handshake_id. The description does not add any additional meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'full state of a handshake', and specifies the components included (parties, presentations, binding, result). This distinguishes it from sibling tools like ep_verify_handshake and ep_initiate_handshake.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to check handshake progress or review completed exchanges', providing clear context for when to invoke this tool. However, it does not state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by stating the return states (valid/expired/not_found) and that it returns scope details, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the purpose and immediately follows with usage guidance and expected returns. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description adequately explains the return values and usage context. It could add more details about when a delegation might be expired, but it is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds marginal context by implying that action_type must be within the delegation's scope, but the schema already states 'must be in delegation scope'. No significant additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'verify' and the resource 'delegation', and specifies it checks for a valid delegation from a principal for a specific action. This distinguishes it from sibling tools like ep_create_delegation or ep_revoke_handshake.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this before accepting a task from an agent claiming to act on behalf of a human', providing clear when-to-use context. However, it does not mention when not to use or compare with similar verification tools like ep_verify_commit or ep_verify_receipt.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnlyHint=true, the description adds behavioral detail by explaining the verification process (signature and Merkle inclusion) and the return structure (valid/invalid, claim fields, anchor status). It aligns with annotations and provides additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences. The first sentence front-loads the core purpose, and the second sentence adds return details and a usage statement. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers purpose, behavior, returns, and use case. It could mention error conditions or what happens with invalid IDs, but overall it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the parameter with its ID format (ep_rcpt_...). The description does not add new semantic information beyond what the schema provides. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it verifies a trust receipt, specifying the target resource exactly ('trust receipt') and the actions (signature and Merkle inclusion verification). It distinguishes from sibling verify tools that handle commits, delegations, or handshakes by focusing on receipts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'use it to independently confirm a receipt was issued by EP and has not been tampered with.' It does not explicitly exclude alternative tools or mention when not to use, but the context of use is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns either 'APPROVED' or 'BLOCKED' and involves human authorization. Annotations already indicate readOnlyHint=false, so the description adds value by detailing the workflow and the need for polling. It could mention idempotency or side effects but is strong overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the core purpose. It is efficient with no wasted words, though a bit more structure (e.g., bullet points) could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, security-critical role, no output schema), the description adequately covers the workflow (submission, approval/blocked, polling). It does not cover error handling or rate limits but is sufficient for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 8 parameters. The tool description adds context (e.g., examples for action_type, summary as human-readable) but does not significantly expand on parameter meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a required guard before irreversible actions, listing specific examples like payments, deletions, and account changes. It distinguishes itself from sibling tools by describing the approval/blocked result and referencing ep_check_signoff for polling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when the tool is required (before any irreversible action) and warns against executing the action without an approved result. It also provides clear guidance on what to do if blocked (poll ep_check_signoff).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces this and adds valuable behavioral details: possible return states (accepted, rejected, partial) and that reason_codes are provided. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place. Front-loaded with purpose and key constraints (read-only, no mutation). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and clear annotations, the description covers all necessary context: what it does, when to call, and what outcomes to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter handshake_id, so no additional explanation is needed beyond the schema. The description does not add extra parameter semantics, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates all presentations in a handshake against its policy, and distinguishes from sibling verification tools like ep_verify_commit and ep_verify_delegation by focusing on handshake-level evaluation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call after parties have added presentations, providing a clear when-to-use instruction. It does not explicitly name alternatives but the context makes the purpose distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it is a poll operation, returns three statuses (PENDING, APPROVED, DENIED with reason), and is safe to call repeatedly. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action, and every sentence adds essential information. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single parameter and no output schema, the description adequately covers the tool's behavior, returns, and safety. It could mention that the return format is not structured but the listed statuses suffice for an agent to act.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description explains the parameter 'receipt_id' by stating it is passed and explicitly ties it to the output of ep_guard_action, adding meaning beyond the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: polling a pending authorization after a specific trigger (ep_guard_action returns BLOCKED). It identifies the specific resource (receipt_id) and distinguishes it from sibling tools like ep_guard_action or ep_verify_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool (after ep_guard_action returns BLOCKED) and that it is safe to call repeatedly. It implies the context but does not explicitly state when not to use it, though the sibling list makes it clear this is the only polling tool for signoff.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=true. The description adds critical behavioral context: revocation is terminal and only parties can perform it. This goes beyond the annotations and helps the agent understand the irreversible nature and access restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each essential. The first sentence states the action, the second specifies who can use it, and the third describes the consequence. No redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two required parameters and no output schema. The description covers purpose, constraints, and irreversible consequence. It could optionally mention the response format, but for a revocation tool the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description does not add any additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Revoke an active handshake', specifying the verb (revoke) and resource (handshake). It also adds context that only parties may revoke and that revocation is terminal, distinguishing it from sibling tools like ep_get_handshake or ep_verify_handshake.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage conditions: 'Only parties to the handshake may revoke it' and 'Revocation is terminal — the handshake cannot be reopened.' This tells when to use (when termination is needed) and when not to (if not a party or if reopening is intended). It doesn't explicitly name alternative tools but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description reinforces read-only nature and adds detail on what verification entails and what output fields are returned. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with key information front-loaded. No redundant phrases. Efficiently conveys purpose, behavior, and usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, rich annotations, and no output schema, the description adequately explains what the tool does and what it returns. Minor omission: does not mention what happens if the commit doesn't exist (error behavior) but acceptable for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and provides the parameter description 'Commit ID (epc_...)'. Description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes a specific verb (verify) and resource (commit), with explicit details on what it does: checks signature, status, validity, and returns valid/invalid along with status, decision, expiry. Distinguishes from sibling tools like ep_get_commit_status which likely only retrieves status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use before relying on or consuming a commit to confirm it is genuine and still active.' No mention of alternatives but given clear purpose, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds that it returns requirements and families, which is useful behavioral context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. Every sentence provides essential information: what it does and when to use it. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains what the tool returns (all policies with requirements and families). For a simple list operation with zero parameters and good annotations, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so baseline is 4. The description adds value by describing what the output contains (policies with requirements and families), which compensates for the lack of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available trust policies with requirements and families, and explicitly says to use for discovering which policy to evaluate. This is specific and distinct from sibling tools that handle presentations, commits, handshakes, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to discover which policy to evaluate against,' providing clear when-to-use guidance. It does not state when not to use or mention alternatives, but the context from sibling tools implies this is the list/discovery tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, readOnlyHint=false), the description adds critical behavioral details: 'SIDE EFFECT: terminally cancels the commit — it can never be consumed after this, and the change is irreversible.' It also mentions 'Requires auth.' No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core action and side effect. Every sentence adds value without redundancy. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, annotations, and full schema coverage, the description covers all necessary context: what it does, side effects, auth requirement, and return value ('Returns the revoked status'). No output schema exists, but the description suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (commit_id, reason). The description does not add extra meaning beyond specifying 'Commit ID to revoke' and 'Reason for revocation' as already present in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Revoke an active pre-action commit before it is fulfilled or expires.' This specifies the verb (revoke), resource (commit), and condition (active, pre-action). It distinguishes from sibling tools like ep_issue_commit or ep_verify_commit by focusing solely on revocation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'use when a pending action should be called off.' It also implies when not to use by noting the irreversible side effect. However, it does not explicitly mention alternatives or conditions to avoid, though no direct alternative exists in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read operation. The description goes further by detailing the returns ('allow / review / deny with reasons') and the evaluation factors (publisher, permissions, provenance, trust history), providing rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with the first sentence immediately stating the purpose and trigger in imperative form. No wasted words; every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description covers the purpose, usage context, evaluation criteria, and return types well. However, it does not detail the trust policy structure or provide comparisons to sibling tools, which would make it even more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are described in the input schema (100% coverage), so the baseline is 3. The description adds value by explaining the policy types enumerated (github_private_repo_safe_v1, npm_buildtime_safe_v1, etc.) beyond the schema's generic description, and by contextualizing the install process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'BEFORE installing or enabling third-party software an agent depends on — check it here.' It specifies the verb (check), resource (third-party software), and scope (pre-installation). The description distinguishes the tool from its siblings by explicitly defining its unique role as a preflight check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'BEFORE installing or enabling third-party software.' It provides clear context for usage, but does not explicitly state when not to use it or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint=false and destructiveHint=false. The description adds critical behavioral details: the operation appends claims, supports three disclosure modes, requires auth, and returns presentation count and handshake state. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the core action, then detail behavior, then provide sequencing and return info. Every sentence contributes meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, nested objects, and no output schema, the description covers the essential context: action, sequencing, auth, and return values. It could further describe the structure of the 'claims' object, but the schema description mitigates this gap. Adequate for agent action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 6 parameters. The description adds value by grouping disclosure modes and claims, explaining the broader purpose of these parameters in the context of identity presentations. This enhances understanding beyond the schema's individual definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and resource 'identity presentation to an active handshake'. It distinguishes from siblings by specifying the call order (after ep_initiate_handshake, before ep_verify_handshake), making the tool's role in the handshake protocol unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use guidance: 'Call after ep_initiate_handshake and before ep_verify_handshake.' Also notes the WRITE nature and auth requirement, eliminating guesswork about the tool's placement in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![emilia-protocol MCP server](https://glama.ai/mcp/servers/emiliaprotocol/emilia-protocol/badges/card.svg)](https://glama.ai/mcp/servers/emiliaprotocol/emilia-protocol)

Score Badge

Copy to your README.md:

[![emilia-protocol MCP server](https://glama.ai/mcp/servers/emiliaprotocol/emilia-protocol/badges/score.svg)](https://glama.ai/mcp/servers/emiliaprotocol/emilia-protocol)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/emiliaprotocol/emilia-protocol'

If you have feedback or need assistance with the MCP directory API, please join our Discord server