How do I use evernode-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@evernode-mcp Generate an escrow dApp template" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

evernode-mcp

by Hugegreencandle

Overview Schema Related Servers Score Discussions

TypeScript

Remote

evernode-mcp — Evernode AI Builder

A Model Context Protocol server that lets an AI agent build, check, cost, and deploy HotPocket dApps on Evernode / Xahau. Point any MCP-capable agent (Claude, etc.) at it and ask for a dApp — it scaffolds a deterministic-by-construction contract, heuristically checks it won't break cluster consensus, estimates the EVR lease, ranks live Evernode hosts, generates the deploy commands, and — when the dApp moves value on Xahau — hands the settlement Hook off to the trifecta to be proven safe.

HotPocket is Evernode's contract runtime: it runs your Node.js/WASM contract on every node of a cluster and puts the output + state through consensus. The single biggest beginner mistake is non-deterministic code (Date.now(), Math.random(), fetch(), …) — two nodes compute different results and the ledger stalls. This server is built around catching that.

It is advisory and read-only: it generates files + guidance, never holds keys, never spends EVR, never acquires a lease, never signs or submits, and it connects to the Offledger Cluster Manager rather than replacing its orchestration.

Where it fits — the layer-2 companion to the Hooks trifecta

The Hooks pipeline secures layer-1 Hooks — write → simulate one tx → prove all inputs → watch live:

stage	tool	what it does
write	xahc	author + compile a safe Hook to clean, lint-passed WASM
simulate one	xahau-mcp	run the real bytecode against one live transaction
prove all	xahc-prover	prove an invariant holds for every input in scope — or return the counterexample
watch live	xahc-watch	bind a proof to the deployed hook and continuously attest it (alerts on a `SetHook` swap or a live verdict break)

evernode-mcp is the layer-2 companion: it builds the HotPocket dApps that run on Evernode hosts. Whenever a dApp settles value on Xahau through a Hook-guarded account, it hands off to the trifecta — it never re-asserts settlement safety itself (check_hook_compat / generate_settlement emit the trifecta's prove/install commands, not a safety verdict).

Related MCP server: NEAR Contract Deployer MCP Server

Tools

All twelve tools are read-only / advisory. Every tool sets readOnlyHint: true; only the two live OnLedger tools (recommend_hosts, host_diagnostics) set openWorldHint: true (they may reach a live external endpoint, OnLedger). Each tool publishes an output schema, so an agent gets a validated structuredContent shape (not just text) — no guessing field names.

tool	open world?	returns
`list_templates`	no	`{ templates }` — the 10 available dApp template names.
`generate_contract`	no	`{ template, files, notes }` — a complete, determinism-clean HotPocket file set (contract + state helper + `hp.cfg.override` + `package.json` + client) for a template.
`check_determinism`	no	`{ findings, summary }` — the differentiator. A heuristic scan of contract source for non-deterministic patterns (wall-clock, randomness, network I/O, env/host reads, timers, unordered iteration, locale/timezone formatting, floating-point literals) that break cluster consensus. Each finding has `line/column/rule/severity/why/fix`. HIGH findings are likely consensus breakers. Guidance, not a proof.
`check_contract_api`	no	`{ findings, summary }` — sibling to `check_determinism` (same honest framing — guidance, not a proof). A heuristic static check that a HotPocket Node.js contract uses the contract API correctly: an `hpc.init(...)` entry point, reading `ctx` (`users`/`lclSeqNo`), persisting ONLY through the consensused state mechanism (no arbitrary `fs` writes to non-state paths), handling `ctx.users` I/O, using `ctx.lclSeqNo` for time (not `Date.now`), and awaiting async consensus ops. Each finding has `line/column/rule/severity/why/fix`.
`recommend_pattern`	no	`{ pattern, nodes, notes }` — given a plain-English use-case, the HotPocket pattern: node count, state model, oracle/NPL usage, Xahau settlement, and the determinism caveats that matter.
`check_hook_compat`	no	`{ involvesHook, workflow, repos }` — when a dApp settles via a Xahau Hook, the exact write → simulate → prove handoff to the trifecta (xahc · xahau-mcp · xahc-prover).
`generate_settlement`	no	`{ template, limitDrops, files, install, prove, notes }` — cluster-side Xahau payout code + the `install` of the trifecta's PROVEN `agent_guardrail` Hook (per-tx `LIM` + optional `DST` lock) + the exact `xahc prove` command. "Safe by construction → proven safe": the ledger enforces the cap even if the contract/signer is wrong. Accepts `escrow` / `subscription` / `payment_splitter` / `streaming_payment` / `multisig_treasury`.
`estimate_lease_cost`	no	`{ inputs, perNodeEVR, totalEVR, approxDurationHours, notes }` — tenant EVR lease = `evrPerMoment × moments × nodes`. Honest: rates are host-set (no network standard); host-side registration fees are excluded.
`recommend_hosts`	yes	`{ mode, ranked, prefer, note, source?, query? }` — fetch + rank live Evernode hosts from OnLedger (real-time from the Xahau registry hook) by `cheap` / `capacity` / `reputation`, with filters (min reputation/slots/RAM, country) — or rank a `hosts` list you supply. Real data only — never invents hosts; honest empty + note on fetch failure.
`host_diagnostics`	yes	`{ found, address, source, note?, registration?, reputation?, slots?, lease?, specs?, redFlags }` — health view of a single Evernode host by r-address: registration status, reputation, active/total/available slots, lease terms (rate/drops if available), specs, and red-flags (low reputation, full capacity, flagged/stale). Fetches live from OnLedger — or diagnose a `host` object you supply. Real data only: numeric fields are soundly coerced (a string-typed numeric like `"252"` becomes a real number; garbage / non-finite values are omitted, never a fabricated `0`); unknown fields are omitted (never invented); honest `found:false` + note on not-found / fetch failure.
`generate_deploy_commands`	no	`{ steps, notes }` — command sequences for `local` (hpdevkit dev cluster) · `single` (evdevkit acquire one host) · `cluster` (evdevkit N-node) · `cluster-manager` (connect to the Offledger Cluster Manager).
`explain_error`	no	`{ matched, explanations? / message? }` — map a HotPocket/Evernode error to cause + fix (connection, consensus stall, no hosts, insufficient EVR, lease expiry, docker/Sashimono, Hook rejection).

Templates

generate_contract ships 10 templates. Each is deterministic by construction (no wall-clock, no randomness, no network in the contract path; time is the consensus ledger seq ctx.lclSeqNo; state persists only through the contract's own consensused state file) and is dogfooded clean through check_determinism (no HIGH findings) and check_contract_api by the smoke test and the suite.

template	what it is	determinism note
`blank`	minimal echo contract — a starting point.	echoes input + `ctx.lclSeqNo`.
`escrow`	depositor locks an amount-claim for a beneficiary, released after a deadline.	deadlines are ledger sequences, not timestamps.
`subscription`	users subscribe for N ledger-rounds; access granted while `lclSeqNo < expiry`.	pure ledger-seq accounting.
`game_backend`	turn-based per-user scores + leaderboard.	leaderboard sorts with a code-point pubkey tiebreaker (not `localeCompare` — host ICU collation diverges) so ordering is deterministic.
`voting`	one-vote-per-pubkey poll with tally.	tally iterates a sorted key view; votes keyed by pubkey dedupe.
`token_gated`	gated access via an admin-maintained allowlist.	does not read an on-chain balance from contract logic (non-deterministic) — uses a consensused allowlist/oracle attestation.
`payment_splitter`	records deposits, computes weighted splits in integer drops.	remainder to the last recipient so payouts sum exactly (no rounding leak); actual payout is a separate Xahau multisig step (see `generate_settlement`).
`oracle_consumer`	the canonical hard pattern: brings external data in via NPL agreement (nodes agree on the value before acting), never a direct fetch.	nodes PROPOSE their observation over the Node Party Line and only ACT on a strict-majority agreed value (a primitive, so its canonical form is byte-identical); disagreement is a deterministic no-op; the agreed datum is stamped with `ctx.lclSeqNo`.
`streaming_payment`	per-ledger-seq vesting: releasable amount is `release = f(ctx.lclSeqNo)`.	pure function of the consensus clock, integer drops only (no float divergence); the contract RECORDS the release — the actual transfer is deferred to `generate_settlement`.
`multisig_treasury`	records spend proposals + M-of-N approvals (threshold).	approvals keyed by signer pubkey, counted over a sorted view; on reaching the threshold it emits the settlement step to `generate_settlement` (ties the trifecta in) — the contract never signs/spends.

Each generated file set carries notes including "before deploy: run check_determinism on src/index.js — HIGH findings break consensus."

Why the determinism check matters (and exactly what it does / doesn't catch)

HotPocket consensuses contract output across every node. If two nodes diverge — because you called Date.now(), Math.random(), fetch(), or read process.env, or iterated an unordered collection built in a non-consensused order — consensus breaks and the ledger stalls. check_determinism flags these before you deploy.

It is a heuristic linter, not a prover — a source scan (mostly per-line regex, plus a small cross-line alias pass), so it is guidance, never a guarantee. Design bias (deliberate): for this tool a false-negative (silently missing a real consensus breaker) is the worst outcome, so when a construct could iterate/serialize an unordered collection but can't be proven sorted, it is flagged. A false-positive (flagging safe code) only costs you a justification.

Now covered (each with a why + a concrete fix):

Wall-clock — Date.now, performance.now, process.hrtime[.bigint], new Date() (HIGH).
Randomness — Math.random, crypto.randomBytes/randomUUID/randomInt/randomFill[Sync]/getRandomValues (HIGH).
Network I/O — fetch/axios/got/node-fetch, require('https'|'net'|'dns') (HIGH).
Per-node env — process.env/process.pid, os.hostname/networkInterfaces/cpus/freemem/loadavg/uptime/userInfo/platform/arch/tmpdir/endianness (HIGH).
Timers / race — setTimeout/setInterval/setImmediate, Promise.race/any (MEDIUM).
Filesystem — fs.read*/write*/stat/readdir outside the sanctioned state file (MEDIUM).
Unordered iteration — for..in, and Object.keys/values/entries + Map/Set for..of (LOW). Sorted views (Object.keys(o).sort(), Object.entries(o).sort(...)) are recognized and not flagged.
Aliased Map/Set (LOW) — a variable or a member (this.m = new Map(), state.m = new Set()) bound to new Map()/new Set() then iterated / spread / forEach'd / Array.from'd / .entries()/.keys()/.values() on a later line (the cross-line alias pass — now covers member-expression aliases, not just plain identifiers).
Member-expression for..of (LOW) — for (const x of this.m / state.m / obj.m) even with no Map/Set evidence: order-unprovable, so flagged. Known deterministic array members (user.inputs/outputs) and call expressions (ctx.users.list()) are recognized and not flagged.
Spread / Array.from materialization (LOW) — [...map], [...Object.values(o)], Array.from(set) that materialize insertion order into an array; suppressed when immediately .sort()-ed.
.forEach (LOW) — over an Object view or new Map/Set; suppressed when sorted first.
JSON.stringify of an unordered object (LOW) — a bare object identifier or a spread/merge whose key order isn't provably consensused (the serialized output/state is consensused byte-for-byte). Fixed-key object literals, arrays, primitives, a sorted replacer array, and .sort()-ed arguments are recognized as safe and not flagged.
Locale / timezone / ICU (MEDIUM) — toLocaleString / toLocaleDateString / toLocaleTimeString, localeCompare, and Intl.*. These depend on the host's locale + ICU collation/format data (and timezone), which differ across nodes — the produced string or sort order diverges. Fix: locale-independent formatting + a code-point comparison (a < b ? -1 : a > b ? 1 : 0), never localeCompare.
Floating-point literals (LOW) — a non-integer float literal (e.g. 0.1, or a negative-exponent scientific literal 1.5e-3 / 1e-3) or parseFloat( feeding contract math: float rounding / NaN / -0 can differ across engines/hosts. Fix: integer math only (work in drops, Math.floor(a*n/d)). Integer literals, integer-valued positive-exponent literals (1.5e3 = 1500), and integer division/floor are not flagged.

Still out of scope (documented honestly — these are NOT caught):

Bare float math / untyped division — a / b of two unknown-typed variables (no float literal / parseFloat signal) is too noisy to flag soundly, so it isn't. Only float literals and parseFloat are flagged.
Deeper data-flow — order divergence behind multi-hop aliases (const n = m), function-return values (const m = makeMap()), Map passed in as a parameter, object spreads merged across several statements, dynamically-built call expressions, or a Map reached through a separate-statement reassignment (let m; m = new Map()). The alias pass covers the direct const x = new Map() and the direct member this.m = new Map() cases, not arbitrary data-flow.
Known acceptable false-positives — e.g. [...Object.keys(o)].sort() still fires the base iteration-order rule (the spread hides the .sort() from it); a Date.now() used only for a local log; an order-independent reduction over a Map; an honest array iterated as for (const x of this.list) (a member with no array-allowlist entry). These flag safe code (the acceptable direction) — justify or refactor.

So: it catches the breakers beginners hit, and biases toward over-flagging the iteration/serialize classes — it does not prove determinism. Settlement safety is proven separately by the trifecta (xahc-prover). Always test on a real multi-node cluster before mainnet.

Settlement → the trifecta handoff

When a value-moving dApp (escrow / subscription payout / payment_splitter) pays out on Xahau, it does so from the cluster's multisig account. generate_settlement produces the "safe-by-construction → proven-safe" bundle:

Cluster-side payout code (xahau/settle.js) — the contract decides amounts deterministically under consensus; signing happens OUTSIDE consensus via the cluster's threshold/multisig signer (no single node holds spend power).
The install of the trifecta's already-proven, testnet-validated agent_guardrail Hook on the cluster account, with your per-tx LIM (spend cap, 8-byte big-endian HookParameter) + optional DST (destination lock) — emitted as an unsigned xahc install-tx SetHook to sign offline.
The exact xahc prove command to prove the guardrail invariant on your built WASM.

The bundle emits the prove/install commands — it does not assert a safety verdict itself. Even a buggy or compromised signer set cannot exceed the LIM or pay a non-allowed DST: the ledger rejects it. Deploy only on a PROVEN verdict from xahc prove.

Install

Install straight from GitHub — it builds on install (the prepare script runs tsc):

npm install -g github:Hugegreencandle/evernode-mcp

Or clone and build:

git clone https://github.com/Hugegreencandle/evernode-mcp && cd evernode-mcp
npm install        # `prepare` compiles dist/ automatically
npm run smoke      # offline self-test (templates determinism-clean, checker + math work)
npm test           # the full Vitest suite (offline)

Add to an MCP client (e.g. Claude Code / Desktop):

{ "mcpServers": { "evernode": { "command": "evernode-mcp" } } }

Or point it directly at the built entry:

{ "mcpServers": { "evernode": { "command": "node", "args": ["/path/to/evernode-mcp/dist/index.js"] } } }

Usage

Point any MCP-capable agent at the server and just ask, e.g.:

"Scaffold an escrow HotPocket dApp called vault." → generate_contract
"Is this contract safe for cluster consensus?" (paste source) → check_determinism
"Does this contract use the HotPocket API correctly?" (paste source) → check_contract_api
"Scaffold an oracle dApp that agrees on a price via NPL." → generate_contract (oracle_consumer)
"Is host rHostAddr… healthy enough to lease?" → host_diagnostics (live)
"What pattern should I use for a token-gated forum?" → recommend_pattern
"Find me the 5 cheapest active Evernode hosts in Germany." → recommend_hosts (live)
"Estimate the EVR to run a 3-node cluster for 720 moments at 2 EVR/moment." → estimate_lease_cost
"Generate the safe Xahau settlement for my splitter, capped at 50 XAH." → generate_settlement → then run the emitted xahc prove command.

Dev / test / CI

npm run build      # tsc → dist/
npm test           # build + Vitest (offline; mocks the live OnLedger fetch)
npm run smoke      # node dist/index.js --smoke — offline self-test
node dist/index.js # run as a stdio MCP server

Tests (tests/): determinism (rule coverage incl. the regression floor + new gaps), contractApi (good contract clean + each API-misuse flagged), advisor (lease math, host ranking, error mapping, pattern/deploy branches), templates (per-template build + determinism-clean + per-template invariants), settlement (LIM encoding + trifecta handoff shape), outputSchemas (each handler's real output validates against its published schema), index (end-to-end: every tool driven through an in-memory MCP client, input-schema rejection), hostDiagnostics (healthy / red-flag / not-found / fetch-failure honesty, mocked fetch), and fetch (live-path hardening, mocked).
CI (.github/workflows/ci.yml): on push + PR to main, runs npm ci, npm run build, npm test, and npm run smoke on Node 20.
createServer() is exported from src/index.ts so the server can be driven over an in-memory transport in tests without starting the stdio transport.

Honest scope (recap)

Generates code + guidance; does not acquire leases, sign, or move EVR/XAH. No key custody.
recommend_hosts fetches live from OnLedger (or ranks a list you supply) — it never fabricates host addresses/specs; on fetch failure it returns empty hosts + a note explaining why, never a fabricated fallback.
check_determinism is a heuristic source scan — guidance, not a proof; biased to over-flag the iteration/serialize classes; test on a real multi-node cluster before mainnet.
Settlement safety (Hook spend limits) is delegated to the trifecta, which proves it — this server emits the prove/install commands, never a verdict.

License

MIT © 2026 Dane Brown. Open source; see LICENSE. Not affiliated with Evernode Labs or the Xahau project. check_determinism findings are heuristic guidance, not a guarantee — always test on a multi-node cluster and review before mainnet.

Available Tools

12 tools

check_contract_apiCheck HotPocket contract API usageA

Read-onlyIdempotent

Heuristic static check that a HotPocket Node.js contract uses the contract API correctly: an hpc.init(...) entry point, reading ctx (users / lclSeqNo), persisting ONLY through the consensused state mechanism (no arbitrary fs writes to non-state paths), handling ctx.users I/O, using ctx.lclSeqNo for time (not Date.now), and awaiting async consensus ops. Severity-rated with fix + why. Sibling to check_determinism — guidance, NOT a proof.

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes	the HotPocket contract JS/TS source to check

Output Schema

ParametersJSON Schema

Name	Required	Description
`summary`	No
`findings`	No

TDQS

A3.9/5.0

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.

check_determinismCheck contract determinismA

Read-onlyIdempotent

Heuristic scan of HotPocket contract source for non-deterministic patterns (wall-clock, randomness, network I/O, env, timers, unordered iteration) that break cluster consensus. HIGH findings are likely consensus breakers. Guidance, not a proof.

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes	the contract JS/TS source to scan

Output Schema

ParametersJSON Schema

Name	Required	Description
`summary`	No
`findings`	No

TDQS

A4.3/5.0

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.

check_hook_compatCheck Xahau Hook / WASM compatibilityA

Read-onlyIdempotent

When a dApp settles value on Xahau through a Hook-guarded account, hands off to the trifecta: build/lint the Hook with xahc, simulate it with xahau-mcp, and PROVE the spend invariant with xahc-prover. Returns the recommended workflow.

ParametersJSON Schema

Name	Required	Description	Default
`what`	No	what the hook should enforce, e.g. 'per-tx spend limit'
`involves_hook`	Yes	does the dApp's Xahau account run a Hook?

Output Schema

ParametersJSON Schema

Name	Required	Description
`repos`	No
`workflow`	No
`involvesHook`	No

TDQS

A3.9/5.0

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.

estimate_lease_costEstimate EVR lease costA

Read-onlyIdempotent

Estimate tenant EVR lease cost = evrPerMoment × moments × nodes. Rates are host-set (no network standard); registration fees are host-side, not included.

ParametersJSON Schema

Name	Required	Description
`nodes`	Yes	cluster size
`moments`	Yes	number of Moments to lease
`evr_per_moment`	Yes	host's per-Moment lease rate in EVR (from its offer)
`moment_minutes`	No	Moment window in minutes (default 60)

Output Schema

ParametersJSON Schema

Name	Required	Description
`notes`	No
`inputs`	No
`totalEVR`	No
`perNodeEVR`	No
`approxDurationHours`	No

TDQS

A4.3/5.0

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.

explain_errorExplain an Evernode/HotPocket errorA

Read-onlyIdempotent

Map a HotPocket/Evernode error message to its likely cause and fix (connection, consensus stall, no hosts, insufficient EVR, lease expiry, docker, Hook rejection).

ParametersJSON Schema

Name	Required	Description	Default
`error_text`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`matched`	No
`message`	No
`explanations`	No

TDQS

A4.2/5.0

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.

generate_contractGenerate a HotPocket dAppA

Read-onlyIdempotent

Generate a deterministic-by-construction HotPocket dApp file set (contract + state helper + hp.cfg.override + package.json + client) for a template.

ParametersJSON Schema

Name	Required	Description	Default
`name`	No	project/contract name (default: mycontract)
`template`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`files`	No
`notes`	No
`template`	No

TDQS

A3.8/5.0

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.

generate_deploy_commandsGenerate deploy commandsA

Read-onlyIdempotent

Generate the command sequence for: local (hpdevkit dev cluster), single (evdevkit acquire one host), cluster (evdevkit N-node cluster), or cluster-manager (connect to Offledger Cluster Manager).

ParametersJSON Schema

Name	Required	Description	Default
`host`	No
`mode`	Yes
`nodes`	No
`instance_name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`notes`	No
`steps`	No

TDQS

A3.7/5.0

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.

generate_settlementGenerate safe Xahau settlementA

Read-onlyIdempotent

For a value-moving dApp, generate the cluster-side Xahau payout code + the install of the trifecta's PROVEN agent_guardrail Hook (per-tx LIM + optional DST lock) on the cluster account + the exact xahc prove command. 'Safe by construction → proven safe' — the ledger enforces the spend cap even if the contract/signer is wrong.

ParametersJSON Schema

Name	Required	Description
`dest`	No	optional r-address to LOCK payouts to (the DST hook param)
`template`	Yes
`limit_drops`	Yes	per-tx spend cap in drops (the LIM hook param)
`cluster_account`	No	the cluster's Xahau (multisig) account r-address

Output Schema

ParametersJSON Schema

Name	Required	Description
`files`	No
`notes`	No
`prove`	No
`install`	No
`template`	No
`limitDrops`	No

TDQS

A3.5/5.0

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.

host_diagnosticsDiagnose an Evernode host (live)A

Read-onlyIdempotent

Health view of a single Evernode host by r-address: registration status, reputation, active/total instance slots, lease terms (rate/moments if available), and red-flags (low reputation, full capacity, stale/inactive). Fetches live from OnLedger (api.onledger.net, real-time from the Xahau registry) — or pass a host object to diagnose it. REAL data only: unknown fields are OMITTED (never invented); honest empty + note on not-found / fetch failure.

ParametersJSON Schema

Name	Required	Description	Default
`host`	No	optional: diagnose this supplied host object instead of fetching live
`address`	No	the host's Xahau r-address to look up live on OnLedger

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	No
`found`	No
`lease`	No
`slots`	No
`specs`	No
`source`	No
`address`	No
`redFlags`	No
`reputation`	No
`registration`	No

TDQS

A4.7/5.0

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.

list_templatesList dApp templatesA

Read-onlyIdempotent

List the available HotPocket dApp templates (escrow, subscription, game_backend, voting, token_gated, payment_splitter, oracle_consumer, streaming_payment, multisig_treasury, blank).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`templates`	No

TDQS

A4.3/5.0

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.

recommend_hostsRecommend Evernode hosts (live)A

Read-onlyIdempotent

Fetch + rank live Evernode hosts from OnLedger (api.onledger.net, real-time from the Xahau registry) by cheap | capacity | reputation, with optional filters. Or pass your own hosts list to rank it. Real data only — never invents hosts.

ParametersJSON Schema

Name	Required	Description
`hosts`	No	optional: rank this supplied list instead of fetching live
`limit`	No	max hosts (default 10)
`prefer`	No
`country`	No	2-letter ISO code, e.g. DE, US, JP
`min_slots`	No	minimum free instances (default 1)
`min_ram_mb`	No
`min_reputation`	No	0–255 host reputation floor

Output Schema

ParametersJSON Schema

Name	Required	Description
`mode`	No
`note`	No
`query`	No
`prefer`	No
`ranked`	No
`source`	No

TDQS

A4.5/5.0

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.

recommend_patternRecommend a HotPocket patternA

Read-onlyIdempotent

Given a plain-English use-case, recommend the HotPocket pattern (node count, state model, oracle/NPL usage, Xahau settlement) with the determinism caveats that matter.

ParametersJSON Schema

Name	Required	Description	Default
`use_case`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`nodes`	No
`notes`	No
`pattern`	No

TDQS

A4.3/5.0

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

12 tool updatesv0.5.0Jul 29, 2026
- First observedcheck_contract_api
- First observedcheck_determinism
- First observedcheck_hook_compat
- First observedestimate_lease_cost
- First observedexplain_error
- First observedgenerate_contract
- First observedgenerate_deploy_commands
- First observedgenerate_settlement
- First observedhost_diagnostics
- First observedlist_templates
- First observedrecommend_hosts
- First observedrecommend_pattern

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/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.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

AgentTrust
io.github.eamwhite1
Trustless XRPL escrow oracle for AI agents. Create jobs, verify work, release XRP/RLUSD payments.
Autonomous Agents Blockchain Finance
2
Air Pipe B
io.airpipe
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
Developer Tools CI/CD & DevOps App Automation
191
cerberus-index A
com.cerberusindex
XRPL token rug-checks, issuer reputation & AMM data for AI agents. Pay-per-call USDC via x402.
Blockchain Cryptocurrency
202
InfraPulse A
ai.infrapulse
AI agent infrastructure for discovery, authorization, execution, identity, and signed receipts.
Agent Orchestration Developer Tools
61

Related MCP Servers

Pentagonalofficial
Blockchain AI & Machine Learning Security
Pentagonal-ai
A
license
A
quality
C
maintenance
AI-powered smart contract forge with an 8-agent adversarial security audit system. Generate, audit, fix, and compile Solidity and Anchor/Rust contracts across 8 chains.
Updated a month ago (2026-07-27 19:35 UTC)
7
35
1
MIT
NEAR Contract Deployer MCP
Blockchain Web3 & Decentralized Tech
jim-agent
F
license
A
quality
D
maintenance
Enables AI assistants to deploy, initialize, and upgrade NEAR smart contracts with cost estimation and status checks.
Updated 7 months ago (2026-02-13 12:09 UTC)
5
-
XRP Ledger Testnet MCP Server
Blockchain Cryptocurrency Web3 & Decentralized Tech
MyronKoch
A
license
C
quality
D
maintenance
Enables AI systems to interact with the XRP Ledger Testnet, supporting XRP payments, token operations, NFTs, escrow, DEX trading, and more.
Updated 9 months ago (2025-12-17 22:25 UTC)
51
MIT
evm-agent-toolkit
Blockchain Web3 & Decentralized Tech Code Analysis
0xendale
A
license
A
quality
B
maintenance
An MCP server that gives autonomous coding agents deterministic, schema-validated tools for EVM smart contract development — security scanning, gas profiling, compiler diagnostics, and transaction simulation.
Updated 2 months ago (2026-07-13 02:17 UTC)
9
1
MIT

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

evernode-mcp — Evernode AI Builder

Where it fits — the layer-2 companion to the Hooks trifecta

Tools

Templates

Why the determinism check matters (and exactly what it does / doesn't catch)

Settlement → the trifecta handoff

Install

Usage

Dev / test / CI

Honest scope (recap)

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Pentagonalofficial

Latest Blog Posts

MCP directory API