evernode-mcp

Server Quality Checklist

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

Latest release: v0.5.0
Disambiguation5/5
Each tool targets a distinct aspect of Evernode development: templates, deployment, contract checking, pattern recommendation, host management, and error handling. No two tools have overlapping purposes; even the two static check tools (check_determinism and check_contract_api) address different concerns.
Naming Consistency5/5
Tool names predominantly follow a verb_noun pattern (list_templates, generate_deploy_commands, check_determinism). Minor abbreviations like 'compat' and 'diagnostics' are clear and consistent with the pattern. No mixed casing or inconsistent verb styles.
Tool Count5/5
With 12 tools, the server covers the full pre-deployment workflow for Evernode dApps: template selection, contract generation, static analysis, pattern recommendation, settlement, host discovery, and diagnostics. The count is well-scoped for its purpose.
Completeness4/5
The tool surface is thorough for the development and deployment planning phase, but lacks post-deployment operations such as listing existing dApps, updating, or deleting instances. This is a minor gap, as the core workflow is well-covered.
Average 4.1/5 across 12 of 12 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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.
Add a glama.json file to provide metadata about your server.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint. The description adds that the tool generates safe-by-construction commands and that the ledger enforces spend caps, which aligns with the hints and provides useful behavioral context beyond the structured annotations.
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 two sentences plus a tagline, packed with relevant jargon and purpose. It is concise but could benefit from clearer structure, e.g., bullet points for output items.
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?
Given complexity (4 params, output schema, siblings), the description adequately conveys the main outputs but omits details like return value format, prerequisites (e.g., cluster account must exist), and when to choose this over similar tools. The output schema likely covers return, but usage context is lacking.
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 high (75%), but the description enhances parameter understanding by linking limit_drops to the LIM hook param and dest to the DST lock, adding domain-specific meaning that the schema's generic descriptions lack.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies that the tool generates Xahau payout code, hook install commands, and a prove command for settlements. It is clear but does not explicitly distinguish from sibling tools like generate_contract or generate_deploy_commands, though its domain-specific jargon differentiates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives such as list_templates or generate_contract. The description does not specify prerequisites or exclusions, leaving the agent to infer usage from the name and context.
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, idempotentHint=true, and openWorldHint=false, signaling safe, idempotent operation. The description adds behavioral context by mapping each mode to a specific deployment target (hpdevkit, evdevkit, Offledger Cluster Manager), which goes beyond the annotations. No contradictions are present.
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 single-sentence description is concise and front-loaded with the tool's purpose. However, it could be more structured (e.g., a list) to improve scannability, especially given the four distinct modes. Still, it wastes no words.
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?
Given the presence of an output schema, the description does not need to explain return values. However, it is incomplete regarding parameter usage and does not differentiate from sibling tools (e.g., 'generate_contract') further. The tool's relative simplicity (4 params, 1 required) means a slightly more thorough description would be expected to fully inform selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only explains the 'mode' parameter via the enum values and fails to clarify the purpose or usage of the other three parameters ('host', 'nodes', 'instance_name'). For example, 'host' is ambiguous across modes, and 'nodes' is only implicitly relevant to 'cluster' mode. This leaves significant gaps for the agent.
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 'Generate' and resource 'command sequence', and enumerates four distinct deployment modes ('local', 'single', 'cluster', 'cluster-manager') with brief explanations. This clearly distinguishes the tool from sibling tools like 'generate_contract' or 'generate_settlement', which serve different purposes.
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 the tool should be used when needing deploy commands for the listed environments, but it does not provide explicit guidance on when to use it versus alternatives (e.g., sibling tools) or when not to use it. No exclusions or conditions are stated.
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 provide readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds 'deterministic-by-construction', which aligns with idempotency, and lists output files. However, it does not disclose additional behavioral traits beyond what annotations offer, such as side effects or error conditions.
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 a single sentence of 18 words, highly concise and front-loaded. Every word provides clear information about the tool's purpose and output, with no redundancy or unnecessary detail.
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 (generating multiple files from 10 templates) and the presence of annotations and output schema, the description covers the core purpose and output structure. It lacks details about return values (though output schema exists) or template selection hints, but is largely adequate.
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 50%: the 'name' parameter has a description, but 'template' lacks one. The tool description only mentions 'for a template' without explaining parameter usage, defaults, or semantics. It adds little 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 tool generates a HotPocket dApp file set, listing specific files (contract, state helper, config, package.json, client) from a template. The verb 'generate' and resource 'HotPocket dApp file set' are explicit, and it distinguishes from siblings like list_templates or generate_deploy_commands by focusing on contract creation.
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: generate a contract for a template. However, it does not explicitly state when to use it versus alternatives (e.g., after selecting a template from list_templates, or prerequisites like a template selection). No guidance on 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 already indicate readOnlyHint=true and idempotentHint=true. The description adds significant context: it is a heuristic (not exhaustive), static check, outputs severity-rated results with fixes and reasoning. No contradictions; the description enriches understanding 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, front-loading the core purpose and then detailing specific checks. While it lists many items, each serves to clarify scope. Could be slightly more streamlined, but overall efficient.
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 an output schema exists (not shown but indicated), the description adequately covers the tool's functionality and output nature (severity-rated with fix + why). For a static analysis tool with one parameter, 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 a single parameter clearly described as 'the HotPocket contract JS/TS source to check'. The description does not add further detail or examples for the parameter, so it meets the baseline without adding extra value.
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 performs a heuristic static check of HotPocket Node.js contract API usage, listing specific aspects checked (e.g., hpc.init entry point, ctx usage, state persistence). It also distinguishes itself from the sibling tool check_determinism, making the purpose unambiguous.
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 mentions it is a sibling to check_determinism and notes it provides guidance rather than proof, implying a difference in rigor. However, it lacks explicit guidance on when to use this tool versus alternatives like recommend_pattern or check_hook_compat, leaving the agent to infer usage context.
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=true and idempotentHint=true, which are consistent with the description's mention of 'returns the recommended workflow' (no destructive actions). The description adds that the tool 'hands off to the trifecta' (build, simulate, prove) but does not clarify whether it actually executes these steps or merely recommends them. The return of a workflow is transparent. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences covering the usage scenario and return value. It is fairly concise but could be more direct by starting with 'Checks compatibility by recommending a workflow...' rather than the scenario-first structure. Still, no superfluous content.
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 moderate complexity, presence of an output schema, and well-described parameters, the description covers the high-level purpose and behavior. It explains the three steps of the workflow (build, simulate, prove) and states the return. It doesn't detail the output schema format, but the output schema itself handles that. The description is complete enough for an agent to understand what the tool does.
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 each parameter having a clear description in the schema. The tool description does not add additional context or constraints beyond what the schema provides. For example, 'what' is described as 'what the hook should enforce' in both schema and description, with the schema providing an example. No further enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool returns a recommended workflow for checking hook compatibility when a dApp settles value on Xahau through a Hook-guarded account. The title 'Check Xahau Hook / WASM compatibility' aligns with this. However, the description is somewhat indirect and doesn't explicitly state 'this tool checks compatibility', relying on the scenario and implied purpose. It does not explicitly differentiate from sibling tools like check_determinism, but the specific Hook scenario provides some distinction.
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 specific usage context: 'When a dApp settles value on Xahau through a Hook-guarded account'. This clearly indicates when the tool is applicable. It does not explicitly mention when not to use it or suggest alternative tools, but given the sibling list and unique purpose, the guidance is adequate.
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 read-only and idempotent. The description adds the context that it maps to cause and fix and lists error types, which is moderate added value.
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 a single sentence, front-loaded with the action, and contains 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 output schema exists, the description covers the input and output intent adequately. It lists error categories, providing sufficient context for a low-complexity tool.
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 0%, so the description must compensate. It indicates the input is an error message but does not specify format, examples, or constraints beyond that.
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 'Map' and resource 'error message' and lists specific error categories. It distinguishes from siblings which are about templates, deployments, 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 implies when to use it (when encountering a HotPocket/Evernode error) but does not explicitly state when not to use or provide 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 declare readOnlyHint and idempotentHint; description adds value by detailing scanned patterns and noting that HIGH findings are consensus breakers, with 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 with front-loaded key information; every sentence earns its place with no waste.
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?
With good annotations, single parameter clearly described, and output schema present, the description fully covers the tool's purpose, behavior, and limitations.
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 parameter description is adequate; description adds minimal extra meaning beyond 'scan for patterns'.
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 uses specific verbs ('Heuristic scan') and lists concrete non-deterministic patterns, clearly distinguishing from sibling tools like check_contract_api or generate_contract.
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?
Clearly states the tool is for checking determinism and sets expectations ('Guidance, not a proof'), but does not explicitly contrast with alternatives among siblings.
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 mark as read-only and idempotent. Description adds valuable context: rates are not standardized and registration fees are not included, which are key behavioral traits 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: first gives purpose and formula, second adds critical caveats. 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 simple multiplicative tool with annotations and output schema, description covers all needed context: what it calculates, inputs, and excluded items.
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 baseline 3. Description adds the formula and clarifies evr_per_moment is from host's offer, but doesn't significantly enhance parameter meaning beyond 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?
Clearly states it estimates EVR lease cost with explicit formula and resource (EVR lease). Distinguishes from siblings like list_templates or generate_contract.
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?
Explains rates are host-set and registration fees are excluded, guiding when to use (rough estimate) and what it omits. No explicit alternative, but 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 indicate read-only and idempotent behavior. The description adds value by listing the exact set of templates available, which is behavioral context beyond what annotations provide. It does not contradict any annotation.
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 a single, well-structured sentence that includes all necessary information (verb, object, examples). No filler or redundancy.
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 zero parameters and the existence of an output schema, the description is fully complete. It covers the tool's purpose and the set of templates, with no obvious gaps.
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?
No parameters exist, so the parameter semantics dimension is automatically high. The description is not required to add meaning beyond the schema, which has 100% coverage. Baseline of 4 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 that the tool lists available HotPocket dApp templates and explicitly enumerates them (escrow, subscription, etc.). It distinguishes from sibling tools focused on generation, checking, or estimation.
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 does not provide explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no discussion of usage context, prerequisites, 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 already declare readOnlyHint=true and idempotentHint=true, so the tool is known safe. The description adds behavioral context by mentioning 'determinism caveats', which alerts the agent to important considerations beyond the annotations. 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?
The description is a single sentence that efficiently conveys the tool's purpose and output. It is front-loaded with the key action and resources, with no extraneous information. Every part earns its place.
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 that an output schema exists (to define return structure), the description adequately covers the input (plain-English use-case) and the content of the recommendation (node count, state model, etc.). It is complete for a pattern recommendation tool with one parameter.
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 0%, meaning the description must compensate. It does so by describing the parameter as a 'plain-English use-case', which clarifies the format beyond a generic 'string'. However, it lacks examples or further constraints, so the added value is moderate.
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 function: given a plain-English use-case, recommend a HotPocket pattern covering specific components. It uses a specific verb ('recommend') and resource ('HotPocket pattern'), and implicitly distinguishes from sibling tools like 'list_templates' or 'generate_contract' by focusing on pattern selection based on use-case.
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 conditions use on having a 'plain-English use-case', which provides clear context for when to invoke the tool. However, it does not mention when not to use it or explicitly compare to sibling tools like 'list_templates' or 'check_determinism', missing some guidance on 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 declare readOnlyHint, idempotentHint, and openWorldHint. The description adds real-time source (api.onledger.net), ranking criteria, and assurance of no invented data. This complements annotations without 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: the first efficiently covers source, ranking modes, and filters; the second adds an alternative use case. No superfluous 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 7 optional parameters and existing output schema, the description covers core functionality (fetch/rank/filter) and important behavioral constraints (real data only). Agents have sufficient information to select and invoke correctly.
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 description coverage is 71% (5 of 7 parameters described). The description adds value by explaining the 'hosts' parameter for ranking a supplied list and the 'prefer' parameter's options (cheap/capacity/reputation), going 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 uses specific verbs ('Fetch + rank') and identifies the resource ('live Evernode hosts from OnLedger'). It distinguishes the tool from siblings by focusing on host recommendation, which is unique among the listed sibling tools.
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 clear context: fetch and rank live hosts, or pass your own list to rank. It states when to use it (real data) and what it avoids (never invents hosts). However, it doesn't explicitly exclude alternative tools, though sibling separation is clear.
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?
The description adds significant behavioral context beyond annotations: data source (OnLedger), honesty policy (unknown fields omitted, not invented), and error handling ('note on not-found / fetch failure'). Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and description aligns with these without 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?
The description is three sentences, front-loaded with purpose, and every sentence adds value. 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?
Given the presence of an output schema, the description adequately covers all needed context: purpose, data source, parameters, behavioral traits. It is complete for an agent to correctly select and invoke the tool.
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 adds usage context: 'optional: diagnose this supplied host object instead of fetching live' and clarifies the address parameter's role. This adds value 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 tool's purpose: 'Health view of a single Evernode host by r-address' and lists specific aspects it covers (registration status, reputation, slots, lease terms, red-flags). It distinguishes itself from siblings, which are unrelated (templates, contracts, 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 explains how to use the tool: fetch live from OnLedger or pass a host object. It also sets expectations with 'REAL data only' and handling of not-found/fetch failure. However, it does not explicitly state when not to use it or mention alternatives among siblings, though siblings are clearly different.
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:

[![evernode-mcp MCP server](https://glama.ai/mcp/servers/Hugegreencandle/evernode-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Hugegreencandle/evernode-mcp)

Score Badge

Copy to your README.md:

[![evernode-mcp MCP server](https://glama.ai/mcp/servers/Hugegreencandle/evernode-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Hugegreencandle/evernode-mcp)

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/Hugegreencandle/evernode-mcp'

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